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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
