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

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>

And, to be honest, if they're still failing after a bit we should probably
just remove them as they're unmaintained :)

That said, Dave and I were talking yesterday about needing to fix the gdb
bot :)

-eric

On Thu, Jan 14, 2016 at 9:33 AM Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>
>
> _______________________________________________
> 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/20160114/f6431bd0/attachment.html>

On 01/14/2016 07:02 PM, Eric Christopher wrote:
> And, to be honest, if they're still failing after a bit we should
> probably just remove them as they're unmaintained :)
>
> That said, Dave and I were talking yesterday about needing to fix the
> gdb bot :)
Just wanted to give a headsup. Some people may just have missed to 
update their bots. Also, it would probably be nice to disable the 
remaining bots maybe a day before the commit, such that we do not 
suddenly have a buildbot console full of red bots.

Best,
Tobias