Die GNU autotools

[Tzafrir Cohen]

On Tue, Jan 11, 2011 at 08:57:43PM +0200, Elazar Leibovich wrote:
> On Tue, Jan 11, 2011 at 7:09 AM, Shachar Shemesh <shachar at shemesh.biz>wrote:
> 
> > Sure, it makes total sense to compare a software that is 93 files, about
> > 36,000 lines of code (including tests) and no documented dependencies to
> > VLC, 1340 source files, 590,000 lines of code and tons of understandable
> > dependencies due to external codecs and stuff. I can see how, except for the
> > choice of build system, the two are on par.
> >
> 
> I really don't think the dependencies and sizes really matters for the
> problem I've had, but instead of arguing about it I see your VLC and I raise
> you by the go programming language.
> 
> The go programming language is a fairly complex beast, is cross compiled to
> ARM architecture, support gcc front ends, and does not need any of the
> autotools. http://golang.org/doc/install.html

Dependencies: bison ed gawk gcc libc6-dev make

(They left out bash)

Indeed a bit more complex than re2. Note that they explicitly mention in
that page 'gcc'. They also (see src/env.bash) explicitly look for GNU
make. So yeah, they're portable. As long as you're in a GNU environment.

> 
> You can probably find small details that don't work exactly as they could
> with the autosuite, but this software is working and compiling really easily
> with less maintenance hassle for 99.9% of its users. This is a living
> testimony that projects can have a good build system and be fairly portable
> even without the autosuite, and you must agree with me that the autosuite
> isn't exactly straightforward, and makes simple things more complex:

It is wrapped by a heavy set of scripts. It does not provide you the
familiar interface. The toplevel directory does not have a Makefile or a
script to run. You have to run it directly from the 'src' directory. It
has to be bash. They don't really handle 'make install' (They just
instruct you to point your software to the current directory with PATH.

So yeah. They manage to live without a decent build system for now.

> 
> Using autotools for a very simple piece of software still requires a few
> > steps:
> >
> >    1. Move the Makefile to Makefile.in
> >    2. Run autoscan
> >    3. Edit the configure.in file
> >    4. Run autoconf
> >    5. Test ./configure
> >    6. make any final adjustments
> >
> > If this is simple, I don't want to know what complicated is. Compare that
> to godag http://code.google.com/p/godag/wiki/Compiling or ANT[1], the
> initial script which just compiles everything and keeps dependencies is
> extremely simple.

Now, those steps are required for the initial setup, mostly. Compare
that to the initia setup of a "Makefile" project. You spend hours trying
to debug 'make -n' ang figure out what variable was mis-inherited this
time.

> 
> Maybe in the old days the autotools was mandatory because, you could not
> afford checking things at runtime 

Some of the tests autoconf uses are:

"please try building this program. Does it work?"

And no. The existance of a definition in a header is not good enough (in
many cases). Been there, done that. Now, if you want to check this in
run-time: feel free.

> or compiling things you don't 100% need
> into the executable (thus using config.h to ifdef pieces of code out).

So your kernel has all the debug options enabled? Cool!

> But nowadays this is wrong both from practical POV (you can afford those
> extra bytes in order to make building the software more straightforward),
> and both from philosophical POV, I want the source code to be the same in
> all platforms if possible, and defer the checks I have to make to runtime,
> this makes things easier (a user has a bug - did you compile your software
> with --can-haz-cheeseburget?), 

Also: what if the checks are incorrect? The checks are done on the build
system. Remember $(shell uname)?

Also: How with you replace the existing --with and --enable ? Explicit
'OPTIONFOO=1' flags to make? This makes it pretty easy to give the wrong
command-line. It forces you to use either an extra configuration file or
a wrapper script (which makes debugging more difficult).

> autosuite encourage me to go to this direction.

-- 
Tzafrir Cohen         | tzafrir at jabber.org | VIM is
http://tzafrir.org.il |                    | a Mutt's
tzafrir at cohens.org.il |                    |  best
tzafrir at debian.org    |                    | friend