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

Eric Christopher echristo at gmail.com
Tue Nov 4 11:08:10 PST 2014


On Tue Nov 04 2014 at 11:01:54 AM Matt Arsenault <Matthew.Arsenault at amd.com>
wrote:

> 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> 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>
>> wrote:
>> > >
>> > >
>> > >
>> > > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <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/>).
>> > >
>> > > - 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.
>

I have a script that does this. It takes 3 minutes including install time.
Also, I do this for many people so it's not burdensome.

-eric


>  _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/634732dd/attachment.html>


More information about the llvm-dev mailing list