Dan Nicholson <dbn.lists <at> gmail.com> writes:
> The main goal of the autotools is that the package comes to you ready to
> build with just basic unix tools: shell, make, compiler/linker. So, you tend
> to not want to try to regenerate the build files on your own.
And that's one of the main design flaws:
* Bugs at one place get copied into hundreds of packages.
* It wastes space for autogenerated files in tarballs (and those configure
scripts can often be HUGE, e.g. anything including the KDE 3 acinclude.m4 ends
up with a huge (over a MB) configure script).
* It makes you reliant on the shell, which may be not available (Window$ -
sure, there is MSYS, but having to install MSYS is no better than having to
install e.g. CMake) or very buggy (some proprietary Unix systems, workarounds
for which are littered all throughout the autotools).
* It is unnecessary: Why is it OK to have to install make and not e.g. CMake?
* It leads to non-reproducibility, i.e. programs which only build with
generated files which are very hard to regenerate properly ("fragile" as you
call it), which makes it harder to modify the programs (I've had my fair share
of problems already with programs which were hard to modify because they
depended on some ancient autotools version which was no longer available in
current distributions - the lack of backwards compatibility is a real problem,
using pregenerated files solves this problem only for users, not for
developers), going against the spirit of Free Software, maybe even against the
letter of the GPL.
(CMake is only an example in the above - you could fill in any central build
tool there, like SCons, qmake etc.)
Unfortunately, I don't think all the problems caused by this design flaw can be
fixed within the autotools. What I would suggest to you and other autotools
developers (and that's a serious suggestion!) is:
* improve backwards compatibility: Don't depend on pregenerated files for
backwards compatibility, instead make sure there's a way to use older .ac
and .am files with newer autotools. Keying compatibility features off macros
like AC_PREREQ might work, or maybe something like Java's --source 1.5 (or 1.4
or ...) switch.
* start discouraging shipping pregenerated files, instead make sure that
autoreconf actually works (which mainly amounts to the above point about
backwards compatibility).
But unfortunately, this won't solve the problem of the reliance on the shell,
and as configure.ac scripts can contain arbitrary shell snippets, this can't
really be fixed without a major redesign, the result of which would effectively
no longer be autotools.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
