<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 3, 2014, at 9:51 AM, Eli Bendersky <<a href="mailto:eliben@google.com" class="">eliben@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Nov 3, 2014 at 9:26 AM, Tom Stellard <span dir="ltr" class=""><<a href="mailto:tom@stellard.net" target="_blank" class="">tom@stellard.net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Oct 31, 2014 at 04:31:47PM -0700, Bob Wilson wrote:<br class="">
><br class="">
> > On Oct 31, 2014, at 4:19 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" class="">echristo@gmail.com</a>> wrote:<br class="">
> ><br class="">
> ><br class="">
> ><br class="">
</span><span class="">> > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <<a href="mailto:tom@stellard.net" class="">tom@stellard.net</a> <mailto:<a href="mailto:tom@stellard.net" class="">tom@stellard.net</a>>> wrote:<br class="">
> > Hi,<br class="">
> ><br class="">
> > I would like to propose deprecating the autoconf build system at some<br class="">
> > point in the future. Maintaining two build systems is a hassle not<br class="">
> > only for this project, but also for other projects that use LLVM<br class="">
> > and have to deal with the slight differences in output between the two<br class="">
> > build systems.<br class="">
> ><br class="">
> > It seems like most people are using CMake at this point, so my questions<br class="">
> > to the community are:<br class="">
> ><br class="">
> > - Is there any technical reason why the remaining autoconf users can't switch<br class="">
> > to CMake?<br class="">
> ><br class="">
> ><br class="">
> > 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 class="">
><br class="">
> 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 class="">
><br class="">
> ><br class="">
> > 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 class="">
> ><br class="">
> > -eric<br class="">
> ><br class="">
> > For example, I personally use automake, and the only reason I don't<br class="">
> > use CMake is because it doesn't produce a single shared object<br class="">
</span>> > (e.g. <a href="http://libllvm-3.6.0svn.so/" target="_blank" class="">libLLVM-3.6.0svn.so</a> <<a href="http://libllvm-3.6.0svn.so/" target="_blank" class="">http://libllvm-3.6.0svn.so/</a>>).<br class="">
<span class="">> ><br class="">
> > - What is a reasonable timeframe to allow the remaining autoconf users<br class="">
> > a chance to migrate to CMake?<br class="">
><br class="">
> 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 class="">
><br class="">
> 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 class="">
<br class="">
</span>The main problem is testing. It doubles the testing load to have two<br class="">
build systems, because we need to make sure both build systems work<br class="">
on all platforms.<br class="">
<br class=""></blockquote><div class=""><br class=""></div><div class="">+1 to this. </div><div class=""><br class=""></div><div class="">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 class=""></div><div>So wouldn’t the first step be to fix any cases where the builds are slightly different?</div><div><br class=""></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></body></html>