[Top][All Lists]

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

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

From: Norman Gray
Subject: Custom automakes (was: FYI: fine tune pkgvdatadir (PR/433))
Date: Thu, 12 Aug 2004 18:24:52 +0100


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 ( 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, and, 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 Gray  :  Physics & Astronomy, Glasgow University, UK  :

reply via email to

[Prev in Thread] Current Thread [Next in Thread]