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

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

Hm, given that we can’t yet remove the compiler-rt makefiles, it’s probably best to just make ./configure error with explicit instructions on how to run cmake in a separate build directory.

+1, IMHO. Autoconf-based configure scripts are expected to have certain behaviors (e.g., Autoconf allows one to write a configure script that checks for and runs another autoconf script in a subdirectory with the same --prefix option and other options). I would hesitate to have a non-Autoconf-compliant configure script. Regards, John Criswell

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

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

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

I'm strongly against enabling in-source cmake builds. Apart from being
IMHO bad practise
certain parts of our CMake files may be assuming. the build is out of
source (e.g. I had a patch recently that assumed this because
in-source builds were impossible at the time).

We seemed to be doing fine so far without in-source cmake builds so I
see no good reason to add support for them.

Maybe the request stems from the (common) misunderstanding that the build folder cannot be inside the source dir.

source_dir/build_dir where build_dir is a subfolder of source_dir and doesn't contain any CMakeFiles.txt is *not* an in source build in CMake terms.

An in source build is when source_dir == build_dir and I agree that this shouldn't have to be supported and should be considered a bad practice with CMake and IMO has absolutely no advantage.

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

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

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

-eric

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

I'm strongly against enabling in-source cmake builds. Apart from being
IMHO bad practise
certain parts of our CMake files may be assuming. the build is out of
source (e.g. I had a patch recently that assumed this because
in-source builds were impossible at the time).

We seemed to be doing fine so far without in-source cmake builds so I
see no good reason to add support for them.

+1

It's so hard to achieve clean out-of-source builds when folks start doing in-source-builds... but this is important for maintaining build reproducibility. At the very least, if in-source builds are to be allowed, there ought to be a buildbot that complains when modifications to the source tree happen in out-of-source builds (and perhaps that ought to be something that we have anyway?).

Jon

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

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

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

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.

Sure. Galina? :slight_smile:

-eric

Should have sent this to cfe-dev too for anyone not following llvm-dev.

The llvm-dev thread is here:
http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html

-Chris

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.

The two Hexagon bots (llvm-hexagon-elf and clang-hexagon-elf) are also using configure at the moment. When is the removal of configure planned to take place?

-Krzysztof

The purpose of this thread was to propose removing configure on January 26th. There have been no objections, so I’m assuming that timeline is acceptable.

-Chris

I'm all for having a single system in place, but as I asked in a
different thread
this week, there's no --enable-bindings=none/auto/ocaml/go/... available
in the CMake scripts. My CMake knowledge is purely as a user, so
someone with more experience might want to recreate this.
There's -DLLVM_BINDINGS_LIST, though it doesn't do what one might
expect.

There's likely other ./configure switches as well that need porting to
CMake flags.

I've been happily build llvm via cmake -G Ninja otherwise.