Re: Autoconf/Automake

From: Jerome Lovy <rqe28bj3vfyi4eo@jetable.net>
Date: Jun 16, 2006, 09:06 UTC
Message-ID: <e6tso3$s3s$1@sea.gmane.org>
In-Reply-To: <20060615174833.GA32247@dspnet.fr.eu.org>

Olivier Galibert wrote:

Show 17 quoted lines

> On Thu, Jun 15, 2006 at 10:02:10AM -0700, Linus Torvalds wrote:
> 
>>These days, there aren't fifteen different versions of UNIX. There's a 
>>couple, and it's perfectly ok to actually say "fix your damn system and 
>>just install GNU make". It's easier to install GNU make than it is to 
>>install autoconf/automake.
> 
> 
> You should be careful to separate autoconf and automake.  Autoconf is
> not so bad, and you can make clean, maintainable Makefile.in and
> config.h.in files with it, because it uses simple substitution.  It is
> quite useful to detect available librairies when some are optional,
> and also to lightly[1] ensure that prefix and friends will stay the
> same between make and make install.  Also, especially if you hack a
> little bit to alias 'enable' and 'with', you get a sane interface to
> optional feature selection.  Oh, and to seperate compilation
> directories too (vpath generation).

I fully agree with Olivier. It seems to me that you don't have to buy the whole autoconf/automake/libtool stack to leverage the autoconf functionality. autoconf alone provides the full "autoconfiguration" framework (running scriptlets and setting substitution variables accordingly). You still have to write Makefile.in (with statements looking like: CC=@CC@). Therefore the resulting Makefile is just as beautiful or as ugly as you wrote the initial Makefile.in: you have full control over it.

As for dependencies, one shouldn't confuse what is needed on the autoconfiguration developer's side (in order to build the configure script from the configure.in file) and what is needed on the installer's side to run the configure script and process the generated makefile. The former needs the autoconf package which itself relies on GNU m4. The latter merely needs a decently compatible Bourne shell and a decently compatible make.

On the other hand, what you get with automake is a fully automatically generated makefile, with make targets conforming to the GNU standards. But then you fully loose control over the Makefile: you don't write the Makefile.in anymore (automake does it for you) but rather the terce Makefile.am. In this respect, automake is like imake: you write few lines of (i)makefile, but then you cannot complain if you don't understand what comes in the generated makefile ;-) .

Jérôme Lovy