stepmake/Documentation/automake.yo

   1 article(Automake -- Urgh!)(HWN and JCN)()
   2
   3 sect(Introduction)
   4
   5 Every once in a while, we get comments on our `non-standard' (non GNU
   6 compliant) configuration/compilation system.  In this document, we try
   7 to explain why we built our own system.  We focus on Automake, but of
   8 course writing complex file(Makefile.in)s without generating them
   9 automatically is an even more deadly sin in our opinion.
  10
  11
  12 sect(What's wrong with Automake?)
  13
  14 We have tried to use Automake and found it to be inadequate for our
  15 needs for several reasons.  On the surface the shortcomings to
  16 Automake may seem bugs or "not-yet-completed" features.  However, file(make)
  17 itself is broken, and any tool built on top of file(make) is broken as well.
  18
  19
  20 sect(Irritations)
  21
  22 We'll start with the superficial irritations first:
  23 itemize(
  24 it() there is no intrinsic support for wildcarding; Adding
  25 support for wildcarding adds yet another layer to a top-heavy system.
  26
  27 This may sound silly, but for a fast moving project, with 1250
  28 sourcefiles, one does not want to administer a list of filenames by
  29 hand: files are created, deleted and moved very often, and wildcarding
  30 prevents that distributions miss files.
  31
  32
  33 it() Automake tries to cater for every taste of file(make).  But anyone
  34 who does more than the trivial code(configure; make install) has to
  35 install Automake and GNU make anyway (for example, you need GCC and
  36 GNU Make for dependency tracking).
  37
  38 Automake's universal make support is good for tools that have to be
  39 highly portable, but you have pay in ease of use and speed while
  40 developing.  This means that it is counterproductive to use Automake
  41 for non-essential programs that are under (heavy) development.
  42
  43
  44 it()
  45 Support for filetypes in built in to Automake, and cannot be added on
  46 the fly: Automake is very much targeted at standard GNU packages that
  47 are written in C (or C++) and come with info-pages.  If you want to
  48 add dependencies from TeX() or METAFONT files you are out of luck.
  49 Ditto if you have weird file types (.pod), weird programming
  50 languages, etc.
  51
  52 There are as many file types as there are languages and compilers.
  53 Extending Automake to support all these languages is error-prone, and
  54 creates nasty version dependencies between an Automake-using package
  55 and Automake itself.  A package should be able to supply its own
  56 specific rules and targets.
  57
  58 it() Dependency handling is unreliable in our experience. On
  59 several occasions we had unexplainable errors, that went away after
  60 doing a code(make distclean), and recompile.
  61
  62 it() It is slower, much slower than a tailored solution.  This
  63 diffence in speed can be as large as 800%. (On JCNs machine a
  64 code(make dist) takes 17 minutes in stead of 2) for every distribution
  65 made; this constitutes 45 minutes of irritation on an average hacking-night.
  66
  67 it() For a large project, a specialised file(Makefile) system costs
  68 relatively little extra effort.  The extra effort pays itself back in
  69 speed and control.
  70
  71 it() The file(Makefile)s, file(Makefile.in)s, and extensions
  72 constitute a huge amount of state.  We found it hard to reproduce bugs
  73 in Automake (Strictly spoken they aren't bugs, as we haven't diagnosed
  74 because we couldn't reproduce them.)  )
  75
  76 sect(Fundamental problems)
  77
  78 Many of the fundamental problems can be traced back to flaws in make:
  79
  80 itemize(
  81 it() make is not standardised.  The only decent implementation is
  82 GNU make, and GNU make is not widespread enough to require GNU make for
  83 compiling GNU tools.
  84
  85 it() make does not have enough meta-ness: one cannot manipulate
  86 dependencies and rules in make: they cannot be put in variables,
  87 mapped at lists, etc.
  88
  89 (In our tailor made compilation system, we worked around this
  90 non-feature by using generic include files as a stopgap function
  91 call.)
  92
  93
  94
  95 it() code(VPATH) is a broken concept: programs should not try to be
  96 intelligent on their own; being intelligent is something the
  97 programmer should do.  make should do exactly as it is told, and make
  98 should enable easy formulation of these commands.
  99 )
 100
 101 Automake tries to solve these problems by building on top of this
 102 broken tool: an extra layer of complexity is added, with
 103 self-modifying Makefiles, and different Makefile versions for
 104 maintainer and user.
 105
 106
 107 sect(Conclusions)
 108
 109 We could be called `cheap' for complaining about the above points,
 110 while not even filing decent bugreports.  The reality is that we
 111 ourselves are busy and that we don't find it amusing to hunt for and
 112 fix bugs in a fix (Automake) for a broken tool (make).
 113
 114 It should also be emphasised that we still think that Automake is a
 115 good tool: it is excellent for small projects, and reasonable for big
 116 projects that are fully "standard."  However, for LilyPond, with its
 117 many sourcefiles and many different filetypes we found it unwieldy.
 118
 119 We hope that some day a better replacement for make comes along, so
 120 that the gruesomeness of make and friends may die in oblivion.  (*)
 121
 122 (*) I personally would like to enter a Makefile as functional program,
 123 whose execution caches function results on the disk as files.  But I
 124 shan't bother you further with my vaporware thoughts..