Mail Archives: geda-user/2016/09/12/07:01:10
On Sun, 11 Sep 2016, al davis wrote:
> All of the autotools replacements fail to acknowledge and preserve what
> is good about autotools, and mostly fail to acknowledge and fix the
> problems it has.
>
> good:
> ./configure; make protocol
> the targets are all there
> command line options for packagers
>
> bad:
> code bloat, non-modular, chaotic design
> imposes its chaos all over anything it touches
> bizarre syntax of its own config files
> generated makefile is unreadable
>
>
> Having a list like this is an essential step in making something better.
Exactly this. I considered writing an Autotools replacement once, but
then realized that, if it should be no worse than the Autotools, it would
have to replicate many of their apparent "design flaws". As an example,
they don't assume that there's a working compiler for the build platform
available (e.g., if you're compiling something to be run on a Raspberry
Pi, you don't need an x86_64 compiler). This means that either the
complete build system has to be written in the portable subset of Bourne
shell, or it has to run on the developer's machine, creating a packaged
configure script to be run on the user's machine.
IMHO, the real problem with the Autotools is that most people using them
don't understand what problem they're solving, and how they're going about
doing this. This results in configure.ac and Makefile.am files which try
to work against the Autotools, resulting in the chaos you described.
- Raw text -