llvm dev - Nov 2014 - [LLVMdev] RFC: Timeline for deprecating the autoconf build system?

> On Oct 31, 2014, at 4:45 PM, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> 
> 
> On Fri, Oct 31, 2014 at 4:31 PM, Bob Wilson <bob.wilson at apple.com
<mailto:bob.wilson at apple.com>> 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>> 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.
> 
> What're the particular problems there? I've been using
compiler-rt/asan built from cmake for a while now, but I don't know the
details (perhaps there are particular features, etc)
Answering that question is the first part of what needs to be done.

I’m pretty sure that cmake has nothing that is close to the equivalent of what
is in make/platform/clang_darwin.mk, for example.
>  
> 
>> 
>> 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.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141031/e214d9fa/attachment.html>

> I’m pretty sure that cmake has nothing that is close to the equivalent of
> what is in make/platform/clang_darwin.mk, for example.
That's not even really autotools from what I can tell, just really
hairy makefiles. As a stepping stone they could probably be invoked
directly from CMake (on platforms that have make).

A fully CMake based system would be much better longer term of course
(for speed if nothing else).

Cheers.

Tim.

On Sat, Nov 1, 2014 at 1:33 AM, Tim Northover  wrote:
>> I'm pretty sure that cmake has nothing that is close to the
equivalent of
>> what is in make/platform/clang_darwin.mk, for example.
>
> That's not even really autotools from what I can tell, just really
> hairy makefiles. As a stepping stone they could probably be invoked
> directly from CMake (on platforms that have make).
>
> A fully CMake based system would be much better longer term of course
> (for speed if nothing else).
Given the kind of makefiles CMake generates (where every single target
causes an extra invocation of make), I find this hard to believe.

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus
Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds