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

Mueller-Roemer, Johannes Sebastian Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de
Wed Nov 5 00:18:21 PST 2014


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

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Steven Stewart-Gallus
Sent: Wednesday, November 05, 2014 06:14
To: Dan Liew
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] RFC: Timeline for deprecating the autoconf build system?

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
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list