[LLVMdev] RFC: Timeline for deprecating the autoconf build system?

[Bob Wilson]

> On Nov 3, 2014, at 9:51 AM, Eli Bendersky <eliben at google.com> wrote:
> 
> 
> 
> On Mon, Nov 3, 2014 at 9:26 AM, Tom Stellard <tom at stellard.net <mailto:tom at stellard.net>> wrote:
> On Fri, Oct 31, 2014 at 04:31:47PM -0700, Bob Wilson wrote:
> >
> > > On Oct 31, 2014, at 4:19 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote:
> > >
> > >
> > >
> > > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <tom at stellard.net <mailto:tom at stellard.net> <mailto:tom at stellard.net <mailto:tom at stellard.net>>> wrote:
> > > Hi,
> > >
> > > I would like to propose deprecating the autoconf build system at some
> > > point in the future.  Maintaining two build systems is a hassle not
> > > only for this project, but also for other projects that use LLVM
> > > and have to deal with the slight differences in output between the two
> > > build systems.
> > >
> > > It seems like most people are using CMake at this point, so my questions
> > > to the community are:
> > >
> > > - Is there any technical reason why the remaining autoconf users can't switch
> > >   to CMake?
> > >
> > >
> > > 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.
> >
> > 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.
> >
> > >
> > > 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.
> > >
> > > -eric
> > >
> > > For example, I personally use automake, and the only reason I don't
> > > use CMake is because it doesn't produce a single shared object
> > > (e.g. libLLVM-3.6.0svn.so <http://libllvm-3.6.0svn.so/> <http://libllvm-3.6.0svn.so/ <http://libllvm-3.6.0svn.so/>>).
> > >
> > > - What is a reasonable timeframe to allow the remaining autoconf users
> > >   a chance to migrate to CMake?
> >
> > 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.
> >
> > 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.
> 
> The main problem is testing.  It doubles the testing load to have two
> build systems, because we need to make sure both build systems work
> on all platforms.
> 
> 
> +1 to this. 
> 
> 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.

So wouldn’t the first step be to fix any cases where the builds are slightly different?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141103/89d0bacf/attachment.html>