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

[Matt Arsenault]

On 11/03/2014 09:51 AM, Eli Bendersky 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/>).
>     > >
>     > > - 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.
>
> Eli
>

This is extra burdensome because LLVM requires an ancient version of 
autotools. You need to track down the old versions and install them to 
regenerate the makefiles, which is a lot of unnecessary work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/4add7f97/attachment.html>