Custom automakes (was: FYI: fine tune pkgvdatadir (PR/433))

[Norman Gray]

Alexandre,

On 2004 Aug 11 , at 22.20, Alexandre Duret-Lutz wrote:

> Apparently some people are maintaining local variants of
> Automake or something like that.

Oh yes.

In case anyone's interested, I'll describe the motivation for, and 
effects of, our decision to start using just such a local automake 
variant.

I've spent the last few months `autoconfing' a large scientific codeset 
(www.starlink.ac.uk).  It comprises about a hundred interdependent 
applications and libraries, with around 10 thirdparty components 
sufficiently crucial we keep them in the repository.  It's about 2000 
kLOC (nonsense measure, of course, but popular nonsense), built up over 
20 years, with some of the code (gawd-help-us) that age, and the whole 
having survived a port from VMS a decade ago.  Unsurprisingly, the 
project has accumulated a variety of code, documentation and 
installation conventions which, for one reason or another, we'd like to 
migrate towards a more currently popular (or at least less eccentric) 
set of conventions.

After a certain amount of labour, we now have the whole thing building 
(most days) with a fairly standard autoconf and a moderately customised 
automake; libtool I have left _well_ alone.  The autoconf mods are 
pretty generic extensions, most of which are to do with autoconfing 
Fortran, and the majority of which will be offered back to the autoconf 
folk as likely being of general use.

The automake mods, however, are there to support our code conventions, 
and are of no interest or utility outside.  They cover generating 
makefile rules for project-specific tools, specially-constructed 
executables, extra primaries and prefixes, and building install 
manifests.  I spent some time trying to do this with exotic 
acinclude.m4 hackery, but that rapidly became very precarious.  What 
we've ended up with is a pretty robust system, with much, much, less 
hand-hacked boilerplate than we had before.

One of the disadvantages of this approach is, of course, that we have 
to maintain a custom automake in our source tree.  But for a project 
this size, this dependent on automake, we'd probably be wise to do that 
anyway, and tolerate having to keep our patched automake up-to-date.  
The other disadvantage is cost: it's taken me six to eight months, from 
a standing start, to learn enough about the autoconf and automake 
internals that I can start hacking around, change my mind a couple of 
times about how to approach it, write enough documentation that my 
colleagues could start using the system without becoming automake 
experts, and so on.

What we've gained is that our configuration files, configure.ac and 
Makefile.am, are much more compact and readable than in our previous 
build system, and our various installation rules are satisfied 
automatically and easily.  Further, we can change those rules in future 
by simply adjusting our automake, and they're propagated easily.

An incidental benefit has been that this fairly light trawl through our 
codebase has prompted us to do a variety of long-postponed 
factorisations and rationalisations, and generally preen the code to 
the extent that it now _feels_ a lot better than it did six months ago.

As a final point, I'd like to record my appreciation for the discipline 
and restraint of the automake authors.  One of the reasons I dislike 
Perl is that its flexibility positively encourages hackery, and I know 
how hard it is to write clean and readable code.  But though I can see 
from the comments that the temptation to hackery has been there many 
times, the authors don't appear to have given in _too_ often.

I hope this is interesting or useful to some of you.

All the best,

Norman


--
----------------------------------------------------------------------
Norman Gray  :  Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/  :  www.starlink.ac.uk