Re: Status of libtool 2.2.X?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux