Automake -- Urgh!

                        HWN and JCN


Contents

     1: Introduction
2: What's wrong with Automake?
3: Irritations
4: Fundamental problems
5: Conclusions


1: Introduction


Every once in a while, we get comments on our `non-standard'
(non GNU compliant)  configuration/compilation  system.   In
this  document,  we try to explain why we built our own sys-
tem.  We focus on Automake, but of  course  writing  complex
Makefile.ins  without  generating  them  automatically is an
even more deadly sin in our opinion.


2: What's wrong with Automake?


We have tried to use Automake and found it to be  inadequate
for  our  needs  for  several  reasons.   On the surface the
shortcomings to Automake  may  seem  bugs  or  "not-yet-com-
pleted"  features.   However, make itself is broken, and any
tool built on top of make is broken as well.


3: Irritations


We'll start with the superficial irritations first:

o    there is no intrinsic support for  wildcarding;  Adding
     support  for  wildcarding  adds  yet another layer to a
     top-heavy system.

     This may sound silly, but for a  fast  moving  project,
     with  1250 sourcefiles, one does not want to administer
     a list of filenames by hand: files are created, deleted
     and  moved  very  often,  and wildcarding prevents that
     distributions miss files.


o    Automake tries to cater for every taste of  make.   But
     anyone  who  does more than the trivial configure; make
     install has to install Automake  and  GNU  make  anyway
     (for  example, you need GCC and GNU Make for dependency
     tracking).

     Automake's universal make support  is  good  for  tools
     that  have  to  be highly portable, but you have pay in
     ease of use and speed  while  developing.   This  means
     that  it  is counterproductive to use Automake for non-
     essential programs that are under (heavy)  development.


o    Support for filetypes in built in to Automake, and can-
     not be added on the fly: Automake is very much targeted
     at standard GNU packages that are written in C (or C++)
     and  come  with  info-pages.   If  you  want   to   add


     dependencies  from   or  METAFONT  files you are out of
     luck.  Ditto if you have weird file types (.pod), weird
     programming languages, etc.

     There are as many file types as there are languages and
     compilers.  Extending Automake  to  support  all  these
     languages  is  error-prone,  and  creates nasty version
     dependencies  between  an  Automake-using  package  and
     Automake  itself.   A  package should be able to supply
     its own specific rules and targets.


o    Dependency handling is unreliable in our experience. On
     several  occasions  we  had  unexplainable errors, that
     went away after doing a make distclean, and  recompile.


o    It  is  slower,  much  slower than a tailored solution.
     This diffence in speed can be as  large  as  800%.  (On
     JCNs  machine  a make dist takes 17 minutes in stead of
     2) for every distribution  made;  this  constitutes  45
     minutes of irritation on an average hacking-night.


o    For  a  large  project,  a  specialised Makefile system
     costs relatively little extra effort.  The extra effort
     pays itself back in speed and control.


o    The  Makefiles, Makefile.ins, and extensions constitute
     a huge amount of state.  We found it hard to  reproduce
     bugs  in Automake (Strictly spoken they aren't bugs, as
     we haven't  diagnosed  because  we  couldn't  reproduce
     them.)


4: Fundamental problems


Many of the fundamental problems can be traced back to flaws
in make:


o    make is not standardised.  The only decent  implementa-
     tion is GNU make, and GNU make is not widespread enough
     to require GNU make for compiling GNU tools.


o    make does not have enough meta-ness: one cannot manipu-
     late dependencies and rules in make: they cannot be put
     in variables, mapped at lists, etc.

     (In our  tailor  made  compilation  system,  we  worked
     around  this non-feature by using generic include files


     as a stopgap function call.)


o    VPATH is a broken concept: programs should not  try  to
     be intelligent on their own; being intelligent is some-
     thing the programmer should do.  make should do exactly
     as  it is told, and make should enable easy formulation
     of these commands.

Automake tries to solve these problems by building on top of
this  broken  tool:  an  extra layer of complexity is added,
with self-modifying Makefiles, and different  Makefile  ver-
sions for maintainer and user.


5: Conclusions


We  could  be called `cheap' for complaining about the above
points, while not even filing decent bugreports.  The  real-
ity  is that we ourselves are busy and that we don't find it
amusing to hunt for and fix bugs in a fix (Automake)  for  a
broken tool (make).

It  should  also  be  emphasised  that  we  still think that
Automake is a good tool: it is excellent for small projects,
and  reasonable  for big projects that are fully "standard."
However, for LilyPond, with its many  sourcefiles  and  many
different filetypes we found it unwieldy.

We  hope  that  some day a better replacement for make comes
along, so that the gruesomeness of make and friends may  die
in oblivion.  (*)

(*)  I  personally  would  like to enter a Makefile as func-
tional program, whose execution caches function  results  on
the  disk as files.  But I shan't bother you further with my
vaporware thoughts..