Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Bob Wilson <bob.wilson <at> apple.com>
Subject: Re: RFC: Timeline for deprecating the autoconf build system?
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Friday 31st October 2014 23:31:47 UTC (over 3 years ago)
> On Oct 31, 2014, at 4:19 PM, Eric Christopher  wrote:
> 
> 
> 
> On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard > 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.
 
CD: 19ms