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

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

On Fri, Oct 31, 2014 at 4:31 PM, Bob Wilson <bob.wilson at apple.com>
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>
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)

>
>
> 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         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/20141031/c9bd0add/attachment.html>

> 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>

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.

Even if we are able to test both build systems on all platforms, we
are still creating more work for projects depending on LLVM, because
they also need to do build testing with LLVM libraries from both build
systems, since their outputs are so different.

Would it be possible for you to attempt a CMake ToT build in your
configuration and come up with a list of CMake deficiencies?  It seems
like there may have been a few CMake improvements since you last tried,
and this may help us figure out what the scope of this change would be.

One other idea I had was that maybe we could start deprecating autoconf
one platform at a time, maybe start with Linux and then do others.  This
might make the transition a little smoother.

Thanks,
Tom

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