<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 3, 2014 at 10:00 AM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><br><div><blockquote type="cite"><div>On Nov 3, 2014, at 9:51 AM, Eli Bendersky <<a href="mailto:eliben@google.com" target="_blank">eliben@google.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 3, 2014 at 9:26 AM, Tom Stellard <span dir="ltr"><<a href="mailto:tom@stellard.net" target="_blank">tom@stellard.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, Oct 31, 2014 at 04:31:47PM -0700, Bob Wilson wrote:<br>
><br>
> > On Oct 31, 2014, at 4:19 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
</span><span>> > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <<a href="mailto:tom@stellard.net" target="_blank">tom@stellard.net</a> <mailto:<a href="mailto:tom@stellard.net" target="_blank">tom@stellard.net</a>>> wrote:<br>
> > Hi,<br>
> ><br>
> > I would like to propose deprecating the autoconf build system at some<br>
> > point in the future.  Maintaining two build systems is a hassle not<br>
> > only for this project, but also for other projects that use LLVM<br>
> > and have to deal with the slight differences in output between the two<br>
> > build systems.<br>
> ><br>
> > It seems like most people are using CMake at this point, so my questions<br>
> > to the community are:<br>
> ><br>
> > - Is there any technical reason why the remaining autoconf users can't switch<br>
> >   to CMake?<br>
> ><br>
> ><br>
> > I think Bob was the lead on keeping the autoconf system last year when this came up, there is a PR somewhere in the system about the blocking things that need to work in cmake to get it to happen. I don't know where we are on that list or what features people still need.<br>
><br>
> I’ve come around to the point of accepting the inevitability of moving to cmake, but I think there’s quite a bit of work to be done to get everything to work. The compiler-rt build in particular is problematic.<br>
><br>
> ><br>
> > Personally I still use the autoconf system, but am willing to remove it if we can get to a single system, but all of the requirements need to be handled first.<br>
> ><br>
> > -eric<br>
> ><br>
> > For example, I personally use automake, and the only reason I don't<br>
> > use CMake is because it doesn't produce a single shared object<br>
</span>> > (e.g. <a href="http://libllvm-3.6.0svn.so/" target="_blank">libLLVM-3.6.0svn.so</a> <<a href="http://libllvm-3.6.0svn.so/" target="_blank">http://libllvm-3.6.0svn.so/</a>>).<br>
<span>> ><br>
> > - What is a reasonable timeframe to allow the remaining autoconf users<br>
> >   a chance to migrate to CMake?<br>
><br>
> I don’t know how to answer that. Someone will need to do the work to first identify all the problems and then to get them fixed.<br>
><br>
> Converting everything to cmake will take quite a lot of work. In comparison, the minor hassle of keeping the makefiles working for a bit longer seems pretty insignificant.<br>
<br>
</span>The main problem is testing.  It doubles the testing load to have two<br>
build systems, because we need to make sure both build systems work<br>
on all platforms.<br>
<br></blockquote><div><br></div><div>+1 to this. </div><div><br></div><div>The situation I frequently find myself in is - doing development using CMake + ninja, and then when I need to actually commit to SVN, I need to build & test with the makefile as well because the builds are slightly different, of occasionally make builds fail where CMake + ninja suceeds. And rebuilding all of LLVM + Clang with the makefile build is *slow*, even on a fast machine.</div></div></div></div></div></blockquote><br></div></div></div><div>So wouldn’t the first step be to fix any cases where the builds are slightly different?</div><div><br></div><div>I think it would make sense to scale back on testing with make, but if you’re seeing cases where the builds differ, then fixing those differences will be a prerequisite to dropping make.</div></div></blockquote></div><br></div><div class="gmail_extra">That's true. AFAIR, the differences were due to different flags (or at least order of flags) passed to the compiler in the two cases. I'll report such cases concretely when I run into it again.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Eli</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>