llvm dev - Nov 2014 - [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

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

> 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

On Wed, Nov 05, 2014 at 05:14:02AM +0000, 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.
> 
> > 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
> > 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

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.