llvm dev - Jan 2016 - [RFC] Removing autoconf from trunk

Now that 3.8 is imminently branching with the newly deprecated autoconf I think
it is time to propose a process and timeline for removing autoconf support from
trunk.

At this point I believe there should be no users of autoconf for Clang and LLVM
that are not supported by CMake, so I would like to propose dropping autoconf
support from the cfe and llvm repositories on January 26th (two weeks from
today). I believe this gives sufficient time for users to migrate any remaining
systems off autoconf. If this timeline doesn’t work for you, please speak up.

There are still some problematic use cases for building the compiler-rt
builtins. Specifically bootstrapping cross-compilers is fragile and in some
cases entirely unworkable in CMake. To this end I’m not proposing a full removal
of the compiler-rt makefiles at this time. What I would like to propose is that
on February 2nd we remove autoconf support for all sanitizer runtimes from
compiler-rt.

We will not be removing the makefile build system from the test-suite project.
The CMake build system there is very new, and still nowhere near feature
complete.

For other projects (libcxx, libcxxabi, libunwind…) I’ve not made significant
contributions to these projects, so I’d like to defer to more active
contributors on those projects, but I am unaware of any blocking issues.

Questions, comments, concerns, panic, fire, brimstone?

-Chris

Sounds like a plan.

Should we leave behind a simple ./configure script that checks for cmake,
and if present, runs something like 'cmake -G"Unix Makefiles"
.'? I think
it's nice if the "standard" Unix way of building with
"./configure && make"
keeps working.

Also, we should be able to allow in-source cmake builds once we remove the
makefiles, right?

On Tue, Jan 12, 2016 at 9:35 AM, Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Now that 3.8 is imminently branching with the newly deprecated autoconf I
> think it is time to propose a process and timeline for removing autoconf
> support from trunk.
>
> At this point I believe there should be no users of autoconf for Clang and
> LLVM that are not supported by CMake, so I would like to propose dropping
> autoconf support from the cfe and llvm repositories on January 26th (two
> weeks from today). I believe this gives sufficient time for users to
> migrate any remaining systems off autoconf. If this timeline doesn’t work
> for you, please speak up.
>
> There are still some problematic use cases for building the compiler-rt
> builtins. Specifically bootstrapping cross-compilers is fragile and in some
> cases entirely unworkable in CMake. To this end I’m not proposing a full
> removal of the compiler-rt makefiles at this time. What I would like to
> propose is that on February 2nd we remove autoconf support for all
> sanitizer runtimes from compiler-rt.
>
> We will not be removing the makefile build system from the test-suite
> project. The CMake build system there is very new, and still nowhere near
> feature complete.
>
> For other projects (libcxx, libcxxabi, libunwind…) I’ve not made
> significant contributions to these projects, so I’d like to defer to more
> active contributors on those projects, but I am unaware of any blocking
> issues.
>
> Questions, comments, concerns, panic, fire, brimstone?
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160112/f431ac4c/attachment.html>

> On Jan 12, 2016, at 9:39 AM, Reid Kleckner <rnk at google.com> wrote:
> 
> Sounds like a plan.
> 
> Should we leave behind a simple ./configure script that checks for cmake,
and if present, runs something like 'cmake -G"Unix Makefiles"
.'? I think it's nice if the "standard" Unix way of building
with "./configure && make" keeps working.
My intention had been to leave the configure script having it print an error
directing people to CMake. I hesitate to make the configure script to anything
other than error out because people like to pass arguments to configure.

Maybe if configure is called with no arguments we do a default build, but if
arguments are specified we fail out?
> 
> Also, we should be able to allow in-source cmake builds once we remove the
makefiles, right?
Maybe. In source builds will need all conflicting makefiles to be removed, so
enabling it before all projects have their makefiles removed might be a bit
complicated.

-Chris
> 
> On Tue, Jan 12, 2016 at 9:35 AM, Chris Bieneman via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Now that 3.8 is imminently branching with the newly deprecated autoconf I
think it is time to propose a process and timeline for removing autoconf support
from trunk.
> 
> At this point I believe there should be no users of autoconf for Clang and
LLVM that are not supported by CMake, so I would like to propose dropping
autoconf support from the cfe and llvm repositories on January 26th (two weeks
from today). I believe this gives sufficient time for users to migrate any
remaining systems off autoconf. If this timeline doesn’t work for you, please
speak up.
> 
> There are still some problematic use cases for building the compiler-rt
builtins. Specifically bootstrapping cross-compilers is fragile and in some
cases entirely unworkable in CMake. To this end I’m not proposing a full removal
of the compiler-rt makefiles at this time. What I would like to propose is that
on February 2nd we remove autoconf support for all sanitizer runtimes from
compiler-rt.
> 
> We will not be removing the makefile build system from the test-suite
project. The CMake build system there is very new, and still nowhere near
feature complete.
> 
> For other projects (libcxx, libcxxabi, libunwind…) I’ve not made
significant contributions to these projects, so I’d like to defer to more active
contributors on those projects, but I am unaware of any blocking issues.
> 
> Questions, comments, concerns, panic, fire, brimstone?
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160112/2eb82398/attachment.html>

On Tue, Jan 12, 2016 at 09:35:29AM -0800, Chris Bieneman via llvm-dev
wrote:
> Now that 3.8 is imminently branching with the newly deprecated autoconf
> I think it is time to propose a process and timeline for removing
> autoconf support from trunk.
I don't know about others, but for me autoconf itself is quite useful
and I would prefer to maintain configure.ac still in the LLVM
repository. cmake is not an acceptable dependency for NetBSD, but the
only relevant part for us is the auto-configuring. The Makefiles are
completely uninteresting.

Joerg

On Tue, Jan 12, 2016 at 12:31 PM Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Tue, Jan 12, 2016 at 09:35:29AM -0800, Chris Bieneman via llvm-dev
> wrote:
> > Now that 3.8 is imminently branching with the newly deprecated
autoconf
> > I think it is time to propose a process and timeline for removing
> > autoconf support from trunk.
>
> I don't know about others, but for me autoconf itself is quite useful
> and I would prefer to maintain configure.ac still in the LLVM
> repository. cmake is not an acceptable dependency for NetBSD, but the
> only relevant part for us is the auto-configuring. The Makefiles are
> completely uninteresting.
>
>
For the project we've had the situation where maintaining two build systems
is prone to build breakages of one or the other and have been actively
moving everyone to a single configuration system that can support all of
the various users of the project. It's been announced and worked on fairly
heavily over the last few years.

If you don't have any use for configuration options (i.e. whether or not to
turn on certain features for the build system), it should probably work to
keep the configure script committed locally for NetBSD?

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160112/cda7e787/attachment.html>

On 01/12/2016 06:35 PM, Chris Bieneman via llvm-dev
wrote:
> Now that 3.8 is imminently branching with the newly deprecated autoconf I
think it is time to propose a process and timeline for removing autoconf support
from trunk.
>
> At this point I believe there should be no users of autoconf for Clang and
LLVM that are not supported by CMake, so I would like to propose dropping
autoconf support from the cfe and llvm repositories on January 26th (two weeks
from today). I believe this gives sufficient time for users to migrate any
remaining systems off autoconf. If this timeline doesn’t work for you, please
speak up.
>
> There are still some problematic use cases for building the compiler-rt
builtins. Specifically bootstrapping cross-compilers is fragile and in some
cases entirely unworkable in CMake. To this end I’m not proposing a full removal
of the compiler-rt makefiles at this time. What I would like to propose is that
on February 2nd we remove autoconf support for all sanitizer runtimes from
compiler-rt.
>
> We will not be removing the makefile build system from the test-suite
project. The CMake build system there is very new, and still nowhere near
feature complete.
>
> For other projects (libcxx, libcxxabi, libunwind…) I’ve not made
significant contributions to these projects, so I’d like to defer to more active
contributors on those projects, but I am unaware of any blocking issues.
>
> Questions, comments, concerns, panic, fire, brimstone?
Hi Chris,

thanks for pushing this forward. I am very much in favor of dropping 
configure.

One issue that I believe has not yet been addressed is to move our 
existing buildbots to cmake. Looking at the config/builders.py a lot of
them have already been moved, but there seem to still be a couple that
did not yet switch. Did anybody an analysis regarding which bots still
need to be updated?

Best,
Tobias

Tobias,

My hope is that now is the time when owners of bots using autoconf will be
migrating them to CMake, however I don’t expect that all the autoconf bots need
to be migrated. My strong suspicion is that many of the autoconf bots that are
remaining have CMake-equivolent bots already, so they can just be deactivated.

-Chris

> On Jan 14, 2016, at 6:06 AM, Tobias Grosser <tobias at grosser.es>
wrote:
> 
> On 01/12/2016 06:35 PM, Chris Bieneman via llvm-dev wrote:
>> Now that 3.8 is imminently branching with the newly deprecated autoconf
I think it is time to propose a process and timeline for removing autoconf
support from trunk.
>> 
>> At this point I believe there should be no users of autoconf for Clang
and LLVM that are not supported by CMake, so I would like to propose dropping
autoconf support from the cfe and llvm repositories on January 26th (two weeks
from today). I believe this gives sufficient time for users to migrate any
remaining systems off autoconf. If this timeline doesn’t work for you, please
speak up.
>> 
>> There are still some problematic use cases for building the compiler-rt
builtins. Specifically bootstrapping cross-compilers is fragile and in some
cases entirely unworkable in CMake. To this end I’m not proposing a full removal
of the compiler-rt makefiles at this time. What I would like to propose is that
on February 2nd we remove autoconf support for all sanitizer runtimes from
compiler-rt.
>> 
>> We will not be removing the makefile build system from the test-suite
project. The CMake build system there is very new, and still nowhere near
feature complete.
>> 
>> For other projects (libcxx, libcxxabi, libunwind…) I’ve not made
significant contributions to these projects, so I’d like to defer to more active
contributors on those projects, but I am unaware of any blocking issues.
>> 
>> Questions, comments, concerns, panic, fire, brimstone?
> 
> Hi Chris,
> 
> thanks for pushing this forward. I am very much in favor of dropping
configure.
> 
> One issue that I believe has not yet been addressed is to move our existing
buildbots to cmake. Looking at the config/builders.py a lot of
> them have already been moved, but there seem to still be a couple that
> did not yet switch. Did anybody an analysis regarding which bots still
> need to be updated?
> 
> Best,
> Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160114/067739f3/attachment.html>

> One issue that I believe has not yet been addressed is to move our
> existing buildbots to cmake. Looking at the config/builders.py a lot of
> them have already been moved, but there seem to still be a couple that
> did not yet switch. Did anybody an analysis regarding which bots still
> need to be updated?
We have one that's still on autoconf (llvm-linux-mips) but it should be on
cmake soon.

One last reminder to everyone. Today is the day.

I’m going to start removing autoconf around 1:30.

The patches are:
LLVM: http://reviews.llvm.org/D16471 <http://reviews.llvm.org/D16471>
Clang: http://reviews.llvm.org/D16472 <http://reviews.llvm.org/D16472>
Compiler-RT: http://reviews.llvm.org/D16473
<http://reviews.llvm.org/D16473>
Clang-tools-extra: http://reviews.llvm.org/D16475
<http://reviews.llvm.org/D16475>

Once the LLVM patch lands the autoconf builds everywhere will cease to function.

One last big thank you to everyone in the community that made this happen! By
the end of the day today we’ll only be supporting one build system!

-Chris
> On Jan 12, 2016, at 9:35 AM, Chris Bieneman via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Now that 3.8 is imminently branching with the newly deprecated autoconf I
think it is time to propose a process and timeline for removing autoconf support
from trunk.
> 
> At this point I believe there should be no users of autoconf for Clang and
LLVM that are not supported by CMake, so I would like to propose dropping
autoconf support from the cfe and llvm repositories on January 26th (two weeks
from today). I believe this gives sufficient time for users to migrate any
remaining systems off autoconf. If this timeline doesn’t work for you, please
speak up.
> 
> There are still some problematic use cases for building the compiler-rt
builtins. Specifically bootstrapping cross-compilers is fragile and in some
cases entirely unworkable in CMake. To this end I’m not proposing a full removal
of the compiler-rt makefiles at this time. What I would like to propose is that
on February 2nd we remove autoconf support for all sanitizer runtimes from
compiler-rt.
> 
> We will not be removing the makefile build system from the test-suite
project. The CMake build system there is very new, and still nowhere near
feature complete.
> 
> For other projects (libcxx, libcxxabi, libunwind…) I’ve not made
significant contributions to these projects, so I’d like to defer to more active
contributors on those projects, but I am unaware of any blocking issues.
> 
> Questions, comments, concerns, panic, fire, brimstone?
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160126/9b5a65d8/attachment.html>