RFC: Timeline for deprecating the autoconf build system?

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?

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

- What is a reasonable timeframe to allow the remaining autoconf users
  a chance to migrate to CMake?

Thanks,
Tom

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.

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

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

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

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)

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.

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.

Because of these differences between build systems, I decided to start my personal project recently to bring up each build system to equal grounds for a platform which I care (which is FreeBSD). Motivation for this has been to have identical test results (and builds) from each other, in the case autoconf build system is retired.

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?

At least better job could be done for canonicalization of architectures within cmake configurations. For example at the moment some LLVM tests does not run with cmake builds for x86_64 FreeBSD, since it identifies itself as "amd64" for cmake, which cascades down to lit testing infrastructure. That's an easy example what I have faced at least so far.

Pasi

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.

Last time I tried, the CMake build was missing some pieces required
for the Gold plugin. Specifically, the --with-binutils-include
option.

Last time I tried, the CMake build was missing some pieces required
for the Gold plugin. Specifically, the --with-binutils-include
option.

Pretty sure that's been fixed (actually, I don't think it finds
binutils without it now): LLVM_BINUTILS_INCDIR.

Cheers.

Tim.

Must've been fixed. I regularly build with -DLLVM_BINUTILS_INCDIR=...
to build the gold plugin.

Diego.

- Is there any technical reason why the remaining autoconf users can't switch
to CMake?

Last time I tried, the CMake build was missing some pieces required
for the Gold plugin. Specifically, the --with-binutils-include
option.

It is there. I build the plugin and haven't used autoconf in years.

Hi,

I use LLVM as a shared lib.
autoconf builds a single .so for this.
cmake builds multiple .so files.
The multiple .so files are better for me because I only need to link
to the ones I need, and this makes load time quicker.
I notice that Ubuntu creates a single .so file, so it must be using
the autoconf build method

But, before dumping autoconf, I think one of the things that need
fixing is a decision on which is the best method.
1) Single .so files.
2) Multiple .so files.

Then, if (2) is decided on, make autoconf create (2) instead of (1)
Once the output of autoconf and cmake are the same, it will be a
painless transition, and we can then dump autoconf.

Kind Regards

James

Requiring cmake for NetBSD is not acceptable as it is almost as heavy as
a C++ compiler itself. That said, I don't really care about the
Makefiles, just about configure and the associated loggic to craete
Config.h and friends. I would expect FreeBSD to have similar concerns.

Joerg

Requiring cmake for NetBSD is not acceptable as it is almost as heavy as
a C++ compiler itself. That said, I don't really care about the
Makefiles, just about configure and the associated loggic to craete
Config.h and friends. I would expect FreeBSD to have similar concerns.

I don't think the extra dependency is a compelling enough reason to
hold back everyone else.

Tim.

configure.ac itself is several orders of magnitude less maintainance
cost. I already said that I don't care about the Makefiles and FreeBSD
like doesn't either. Heck, I don't mind being the maintainer for it as
long as I get at least a friendly ping when a new feature check is added
to the cmake build system.

Joerg

For the FreeBSD base system, we use a bmake-based build system for LLVM, but that is based on the Makefiles generated by CMake. I believe that we're now using CMake for the version of LLVM in ports.

David

The primary question is how do you create Config.h and friends,
especially the tools version during early release build.

Joerg

We keep the version generated by CMake in the source tree for the version in base. For the version in ports, CMake generates it when it builds.

David

Actually, the llvm/clang config.h (and other .def) files in FreeBSD are generated by autoconf. For the rest we indeed use bmake, but this infrastructure is mostly cobbled together manually. I only use the autoconf build output to determine which libraries are required by each llvm/clang tool, and in which order they are linked.

-Dimitry

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