RFC: Timeline for deprecating the autoconf build system?

Project Infrastructure LLVM Dev List Archives
#1

I am an actual end user of LLVM who builds it from source and not a
developer of it so I think I have an important perspective that is not
represented here. Also I am pretty sure the llvmdev mailing is heavily
biased and might not reach actual end users of LLVM. I use the
Autotools build system for a number of reasons. If compromises or
reasonable workarounds could be found I would be okay with the switch
to CMake.

- CMake is poorly documented and difficult to use as an end
  user. There are a number of arcane switches and settings that are
  hard to find and figure out what they do. Moreover, certain
  important functionality is just plain lacking.

- I already have an Autotools configuration file that sets default
  settings for the local installation prefix (to
  "$HOME/root/usr/local") and the LDFLAGS (to
  "-Wl,-rpath,${HOME}/root/usr/local/lib
  -Wl,-rpath,${HOME}/root/usr/local/lib64"). I don't if it's possible
  to set such defaults for CMake and even if it is the difficulty in
  finding how to do so is a bad sign.

- In Autotols the installation directory is overridable at install
  time so I can set the prefix variable to a different directory such
  as "$HOME/root/usr/local/stow/llvm" and using GNU Stow have easy
  package management and isolation between software. CMake does not
  offer such a capability or is so poorly documentated that it is
  impossible to find out how to do so.

Overall, CMake isn't a bad build system for actually building software
but simply lacks the appropriate polish and documentation that makes
it easy for end users to use.

Thank you,
Steven Stewart-Gallus

#2

Which features, in particular, do you find to be missing?

Cheers,

Jon

#3
  • CMake is poorly documented and difficult to use as an end
    user. There are a number of arcane switches and settings that are
    hard to find and figure out what they do. Moreover, certain
    important functionality is just plain lacking.

Which features, in particular, do you find to be missing?

I was just writing an email to ask this :slight_smile:

In particular, if there are changes you’d like to see to http://llvm.org/docs/CMake.html#frequently-used-cmake-variables then that would be worth discussing (possibly in a separate thread).

Thanks,
Pete

#4

There’s a bug up thread. Those are the problems we knew about last time we asked about this.

-eric

#5

Hi

I am an actual end user of LLVM who builds it from source and not a
developer of it so I think I have an important perspective that is not
represented here. Also I am pretty sure the llvmdev mailing is heavily
biased and might not reach actual end users of LLVM. I use the
Autotools build system for a number of reasons. If compromises or
reasonable workarounds could be found I would be okay with the switch
to CMake.

- CMake is poorly documented and difficult to use as an end
  user. There are a number of arcane switches and settings that are
  hard to find and figure out what they do. Moreover, certain
  important functionality is just plain lacking.

Have you seen the docs for CMake3.0 [1] (see cmake-buildsystem
especially)? They certainly aren't perfect but they are considerably
better than what was there before.

I wouldn't say that much "important functionality is plain lacking",
it probably just isn't documented that well.

- I already have an Autotools configuration file that sets default
  settings for the local installation prefix (to
  "$HOME/root/usr/local") and the LDFLAGS (to
  "-Wl,-rpath,${HOME}/root/usr/local/lib
  -Wl,-rpath,${HOME}/root/usr/local/lib64"). I don't if it's possible
  to set such defaults for CMake and even if it is the difficulty in
  finding how to do so is a bad sign.

Installation prefix is set using the CMAKE_INSTALL_PREFIX cache
variable. You can set it at configure time,

$ cmake -DCMAKE_INSTALL_PREFIX=$HOME/root/usr/local /path/to/llvm/src

you can even change it after configuring easily later by running

$ make edit_cache

which will launch a nicer editor for the variables (e.g. ccmake or cmake-gui).

I'm don't think it's necessary to set the rpath. If you read [2]
you'll see that you can just run the binaries in the build tree and
they have rpath set correctly (the installed binaries have rpath
removed)

If you really wanted to you could probably hack some of CMake's flags
to set rpath but I don't understand why you want to do this. You can
just build against LLVM's build tree to do development.

- In Autotols the installation directory is overridable at install
  time so I can set the prefix variable to a different directory such
  as "$HOME/root/usr/local/stow/llvm" and using GNU Stow have easy
  package management and isolation between software. CMake does not
  offer such a capability or is so poorly documentated that it is
  impossible to find out how to do so.

As mentioned above you can override the installation directory
whenever you like (but it may trigger a rebuild). But you know you can
do this right?

$ make install DESTDIR=/some/path/

So then the project will be installed at

/some/path/<CMAKE_INSTALL_PREFIX>/

Overall, CMake isn't a bad build system for actually building software
but simply lacks the appropriate polish and documentation that makes
it easy for end users to use.

The documentation is probably the biggest problem. I actually quite
liked CMake (apart from its syntax and variable scoping rules) once I
understood the bits I needed to understand.
I probably have a very different perspective from many though given
that I used CMake first and then tried autotools afterwards (I'll be
honest... I don't like it very much).

[1] http://www.cmake.org/cmake/help/v3.0/
[2] http://www.cmake.org/Wiki/CMake_RPATH_handling

#6

Hello, thank you for the thoughts.

Have you seen the docs for CMake3.0 [1] (see cmake-buildsystem
especially)? They certainly aren't perfect but they are considerably
better than what was there before.

Okay, the documentation has come a long way since 3.0 although it
still needs a bit of polish.

I wouldn't say that much "important functionality is plain lacking",
it probably just isn't documented that well.

See the following.

Installation prefix is set using the CMAKE_INSTALL_PREFIX cache
variable. You can set it at configure time,

$ cmake -DCMAKE_INSTALL_PREFIX=$HOME/root/usr/local /path/to/llvm/src

Correct, but I cannot set it as a default in a configuration file so I
need to specify it for every single package that I compile every time
I configure it. I think this a very basic and obvious feature that
CMake should support.

I'm don't think it's necessary to set the rpath. If you read [2]
you'll see that you can just run the binaries in the build tree and
they have rpath set correctly (the installed binaries have rpath
removed)

I do in fact need to set the rpath so that I can link to a higher
version of GCC's C++ standard library implementation installed there
as LLVM does not build against an older version of GCC.

As mentioned above you can override the installation directory
whenever you like (but it may trigger a rebuild).

but it may trigger a rebuild

Yeah, that's not what I want.

But you know you can
do this right?

$ make install DESTDIR=/some/path/

That's not the same behaviour at all!
DESTDIR="$HOME/root/usr/local/stow/llvm" installs to
"$HOME/root/usr/local/stow/llvm/$HOME/root/usr/local" instead of
"$HOME/root/usr/local/stow/llvm" which is silly.

The documentation is probably the biggest problem. I actually quite
liked CMake (apart from its syntax and variable scoping rules) once
I understood the bits I needed to understand. I probably have a
very different perspective from many though given that I used CMake
first and then tried autotools afterwards (I'll be honest... I don't
like it very much).

The fundamental difference between Autotools and CMake is that they
are built for different users. CMake is built for the modern developer
in 2014 on Linux, Windows, Mac OS X or FreeBSD. Autotools is primarily
built for the Free Software enthusiast university student in 1980 who
is compiling a package on his University's Unix like server (which
could be any of many different ones). As such, Autotools is
horrendously difficult for the developer to use but when used properly
is extremely portable and easy to use for the university student who
compiles the project.

Thank you,
Steven Stewart-Gallus

#7

You can use an initial cache file for common settings, see http://www.cmake.org/cmake/help/v2.8.11/cmake.html#opt%3A-Cinitial-cache
On the RPATH issue: If you use the newer compiler, the newer libstdc++ should be used automatically (CMake uses absolute RPATHs by default, these are removed when installing), and which compiler should be used can be specified at configuration time. In general, RPATH is pretty well documented http://www.cmake.org/Wiki/CMake_RPATH_handling
If you want to specify your install path completely using DESTDIR, just set an empty CMAKE_INSTALL_PREFIX...

"Extremely portable" is not how I would describe autotools...

#8

Installation prefix is set using the CMAKE_INSTALL_PREFIX cache
variable. You can set it at configure time,

$ cmake -DCMAKE_INSTALL_PREFIX=$HOME/root/usr/local
/path/to/llvm/src

This touches on a point where I think cmake is a bit weak for end users. With autotools, pretty much everything an end-user needs to know is in './configure --help' and it doesn't normally have too much information. CMake doesn't really have a good equivalent for this. It's clearly trying to achieve the same kind of thing through --help-variable-list, --help-variables, and '--help-variable var' but the latter requires you to know the variable name and the former two print _everything_ (including things like CMAKE_ARGC, and CMAKE_ARGV0). To summarize, CMake is fairly well documented in my opinion but it doesn't guide the end-user very well.

That said, I'm broadly in favour of dropping autotools support. CMake builds are significantly faster in my experience (especially with ninja and BUILD_SHARED_LIBS=ON) and I'm not keen on the testing burden of supporting two build systems.

Tom: You probably already know this but one thing to mention is that utils/release/test-release.sh currently does an autotools-based build.

#9

You can use an initial cache file for common settings, see
http://www.cmake.org/cmake/help/v2.8.11/cmake.html#opt%3A-Cinitial-
cacheOn the RPATH issue: If you use the newer compiler, the newer
libstdc++ should be used automatically (CMake uses absolute RPATHs
by default, these are removed when installing), and which compiler
should be used can be specified at configuration time. In general,
RPATH is pretty well documented
http://www.cmake.org/Wiki/CMake_RPATH_handlingIf you want to
specify your install path completely using DESTDIR, just set an
empty CMAKE_INSTALL_PREFIX...

Doesn't LLVM use CMAKE_INSTALL_PREFIX to find its personal data and
other binaries?

"Extremely portable" is not how I would describe autotools...

To Unix systems in 1980, of course.

Thank you,
Steven Stewart-Gallus

#10

Hey! At least 1990, c'mon!

--renato

#11

Hello, thank you for the thoughts.

> Have you seen the docs for CMake3.0 [1] (see cmake-buildsystem
> especially)? They certainly aren't perfect but they are considerably
> better than what was there before.

Okay, the documentation has come a long way since 3.0 although it
still needs a bit of polish.

> I wouldn't say that much "important functionality is plain lacking",
> it probably just isn't documented that well.

See the following.

> Installation prefix is set using the CMAKE_INSTALL_PREFIX cache
> variable. You can set it at configure time,
>
> $ cmake -DCMAKE_INSTALL_PREFIX=$HOME/root/usr/local /path/to/llvm/src

Correct, but I cannot set it as a default in a configuration file so I
need to specify it for every single package that I compile every time
I configure it. I think this a very basic and obvious feature that
CMake should support.

> I'm don't think it's necessary to set the rpath. If you read [2]
> you'll see that you can just run the binaries in the build tree and
> they have rpath set correctly (the installed binaries have rpath
> removed)

I do in fact need to set the rpath so that I can link to a higher
version of GCC's C++ standard library implementation installed there
as LLVM does not build against an older version of GCC.

> As mentioned above you can override the installation directory
> whenever you like (but it may trigger a rebuild).

> but it may trigger a rebuild

Yeah, that's not what I want.

> But you know you can
> do this right?
>
> $ make install DESTDIR=/some/path/

That's not the same behaviour at all!
DESTDIR="$HOME/root/usr/local/stow/llvm" installs to
"$HOME/root/usr/local/stow/llvm/$HOME/root/usr/local" instead of
"$HOME/root/usr/local/stow/llvm" which is silly.

Hi Steven,

Would you be able to file bugs at www.llvm.org/bugs for these missing
features CMake features and mark them as blocking 15732? This way we
can track them more easily.

Thanks,
Tom

#12

Steven Stewart-Gallus wrote:

Hello, thank you for the thoughts.

Have you seen the docs for CMake3.0 [1] (see cmake-buildsystem
especially)? They certainly aren't perfect but they are considerably
better than what was there before.

Okay, the documentation has come a long way since 3.0 although it
still needs a bit of polish.

The new documentation system is new in CMake 3.0. We welcome additions. I'm
glad the cmake-buildsystem manual I wrote is well-received.

$ cmake -DCMAKE_INSTALL_PREFIX=$HOME/root/usr/local /path/to/llvm/src

Correct, but I cannot set it as a default in a configuration file so I
need to specify it for every single package that I compile every time
I configure it. I think this a very basic and obvious feature that
CMake should support.

I don't understand the problem. Can you re-state it?

As mentioned above you can override the installation directory
whenever you like (but it may trigger a rebuild).

but it may trigger a rebuild

Yeah, that's not what I want.

It won't trigger a re-build.

It only *could* trigger a rebuild of particular files if you use the install
prefix in source code either by generating a header file containing it or
passing it in a -D define. As your workflow apparently depends on something
along the lines of 'make install prefix=/tmp/llvm', that is assuredly not
the case. So,

  It won't trigger a re-build.

The fundamental difference between Autotools and CMake is that they
are built for different users. CMake is built for the modern developer
in 2014 on Linux, Windows, Mac OS X or FreeBSD.

This is definitely not true.

Thanks,

Steve.