[LLVMdev] RFC: Timeline for deprecating the autoconf build system?

[Dan Liew]

Hi

On 4 November 2014 19:01, Steven Stewart-Gallus
<sstewartgallus00 at mylangara.bc.ca> wrote:
> 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
-- 
Dan Liew
PhD Student - Imperial College London