CMake!

[Kevin Kofler]

Callum Lerwick <seg <at> haxxed.com> writes:
>
> On Fri, 2008-10-10 at 15:56 -0400, Braden McDaniel wrote:
> > 
> > If you want upstream to stop using libtool altogether, find a suitable  
> > replacement and convince the Automake developers to use it instead.
> 
> Why the h8? He was speaking in the context of "the state of the art" and
> in my oh-so-humble opinion CMake is it. The whole of the Autotools stack
> is very much... not.

+1

The suggestion to convince the automake developers to use something other than 
libtool is pointless, because automake should also go away, it's at least as 
obsolete, buggy, unable to maintain backwards compatibility, annoying, a 
massive time waster at build time and a major PITA for developers to code with 
as libtool is. The whole autotools stack sucks. It always did, we just didn't 
have anything better. We now do, so why are people still using autotools?

Some of the major design failures of the autotools:
* They work by copying the same sets of files into lots of programs and 
encourage distributing generated files (and break compatibility so often that 
that recommendation is almost always followed), so we end up with dozens of 
programs all having their own copy of the check for some library - if it's 
broken, all those programs need patching (and aclocal is a bad solution to that 
because it involves more pregenerating and copying). A modern build system like 
CMake centralizes the checks so there's just one copy to fix (just like shared 
libraries) and keeps compatibility so programs can rely on a compatible version 
of the build tool to just be there and not ship pregenerated files.
* They're supposed to make programs more portable, but use *nix-only shell 
scripts. (And horribly ugly shell scripts working around bugs in dozens of 
subtly incompatible shells (all claiming to be Bourne-compatible and/or 
POSIX-compliant) at that.)
* Libtool generates .la files even on platforms which don't need them. It's 
ridiculous that we still have to delete unwanted files in almost all packages, 
and even more so that they have a comment on the top saying "DON'T DELETE THIS 
FILE!".
(That said, CMake has a similar dependency tracking feature which, when 
enabled, is similarly broken by default. A package has to either not use 
dependency tracking at all (which may cause problems on some 
platforms/configurations, e.g. static libraries) or use an extra command to do 
the right thing (only linking in indirect deps explicitly if the platform 
requires it). But at least it's possible, unlike libtool where you have to 
manually delete a file which screams not to be deleted.)
* Autoconf defaults (and it's extremely hard to disable that, IIRC you can't 
use some convenient macros almost all programs use and have to use low-level 
stuff) to doing all sorts of useless checks as part of the checks that the 
build environment is "sane", such as:
- checking that ISO C90 (ANSI C89) headers exist (hello??? It's 2008! That 
standard is 18-19 years old now! What totally obsolete systems _still_ not 
supporting them do we want to support?), the results of which are generally 
thrown away (because the program just assumes the ISO C headers exist, and 
rightfully so, and thus doesn't do anything with the HAVE_FOO variables from 
those tests), or
- checking that the Fortran and Java-to-native-code compilers exist (even in an 
all-C/C++ project).
All those totally useless tests waste a lot of time for every single build, 
even of trivial projects.
* Automake has 2 modes, a GNU mode which enforces GNU guidelines and 
a "foreign" mode which doesn't, but for some insane reason, it defaults to the 
GNU mode. This is broken for many reasons:
- A tool should not error when some coding style guideline is broken, at most 
it should warn.
- Most projects using automake these days are NOT GNU projects, it's silly to 
try to enforce GNU's guidelines on those.
- The most annoying thing the "GNU" mode enforces is the presence of some files 
like COPYING (OK, this one makes sense, though IMHO License.txt is a better 
name, we're no longer in the 1980s), INSTALL (which is often a verbatim copy of 
the default GNU INSTALL document added just to make automake happy and thus 
completely and utterly useless), NEWS and AUTHORS (both often completely empty, 
added just to make automake happy) and with these obsolete (the days of systems 
allowing only 7 characters in a file name are long gone!), non-portable names 
(Window$ users expect .txt extensions, and even on GNU/Linux, these days, the 
extensionless names aren't always properly detected as text files).
* Libtool thinks /usr/lib64 needs an RPATH, unless you use a Fedora-patched 
version, in which case it'll think /usr/lib needs an RPATH on x86_64 even on a 
Debian system. So, unless you're about to hack the generated/copied libtool 
scripts manually, there's no way (using libtool) to make a package which will 
generate no bogus RPATHs on x86_64 on at least one distro.

Needless to say, CMake doesn't have the above shortcomings (except for 
dependency tracking, and even that can be made to do the right thing by the 
library project if they know what they're doing; and if they don't know what 
they're doing, they'll probably not bother generating a dependency file at 
all ;-) - CMake doesn't do that by default).

CMake also has cool features like reporting the progress percentage of builds 
during make. And it's way faster too.

        Kevin Kofler