Documentation/automake.urgh

   1
   2 WHAT'S WRONG WITH AUTOMAKE?
   3
   4
   5 We have tried to use automake and found it to be inadequate for our
   6 needs for several reasons.  On the surface the shortcomings to
   7 automake may seem bugs or "not-yet-completed" features.  However, make
   8 itself is broken, and any tool built on top of make is broken as well.
   9
  10
  11 IRRITATIONS
  12
  13 We'll start with the superficial irritations first:
  14
  15         - there is no intrinsic support for wildcarding; Adding
  16 support for wildcarding adds yet another layer to a top-heavy system.
  17
  18 This may sound silly, but for a fast moving project, with 500
  19 sourcefiles, one does not want to administer a list of filenames by
  20 hand: files are created, deleted and moved very often, and wildcarding
  21 prevents that distributions miss files.
  22
  23
  24         - Automake tries to cater for every taste of make.  But anyone
  25 who does more than the trivial (configure; make install) has to
  26 install automake and GNU make anyway.  Automake's universal make
  27 support is good for tools that have to be highly portable, but you
  28 have pay in ease of use and speed.
  29
  30         - Automake is very much targeted at standard GNU packages that
  31 are written in C (or C++) and come with info-pages.  If you want to add
  32 dependencies from TeX or METAFONT files you are out of luck.  Ditto if
  33 you have weird file types (.pod), weird programming languages, etc.
  34
  35         - Dependency handling is unreliable in our experience. On
  36 several occasions we had unexplainable errors, that went away after
  37 doing a make distclean, and recompile.
  38
  39         - It is slower, much slower than a tailor made solution.  On
  40 JCNs machine this is a diffence of 800% (17 minutes in stead of 2) for
  41 every distribution made; this constitutes 45 minutes of irritation on
  42 a hacking-night.
  43
  44         - For a large project, a specialised Makefile system costs
  45 relatively little extra effort.  The extra effort pays itself back in speed
  46 and control.
  47
  48         - The Makefiles, Makefile.ins, and extensions constitute a
  49 huge amount of state.  We found it hard to reproduce bugs in automake
  50 (Strictly spoken they aren't bugs, as we haven't diagnosed because we
  51 couldn't reproduce them.)
  52
  53
  54 FUNDAMENTAL PROBLEMS
  55
  56 Many of the fundamental problems can be traced back to flaws in make:
  57
  58         - make is not standardised.  The only decent implementation is
  59 GNU make, and GNU make is not widespread enough to require GNU make for
  60 compiling GNU tools.
  61
  62         - make does not have enough meta-ness: one cannot manipulate
  63 dependencies and rules in make: they cannot be put in variables,
  64 mapped at lists, etc.
  65
  66 (In our tailor made system, we worked around this non-feature by using
  67 generic include files as a stopgap function call.)
  68
  69         - VPATH is a broken concept: programs should not think on
  70 their own; thinking is the programmer's job.  make should do exactly
  71 as it is told, and make should enable easy formulation of these
  72 commands commands.
  73
  74 automake is tries to solve these problems by building on top of this
  75 broken tool: an extra layer of complexity is added, with
  76 self-modifying  Makefiles, and different Makefile versions for
  77 maintainer and user.
  78
  79
  80 CONCLUSIONS
  81
  82 We could be called "cheap" for complaining about the above points,
  83 while not even filing decent bugreports.  The reality is that we
  84 ourselves are busy and that we don't find it amusing to hunt for and
  85 fix bugs in a fix (automake) for a broken tool (make).
  86
  87 It should also be emphasised that we still think that automake is a
  88 good tool: it is excellent for small projects, and reasonable for big
  89 projects that are fully "standard."  However, for LilyPond, with its
  90 many sourcefiles and many different filetypes we found it unwieldy.
  91
  92 We hope that some day a better replacement for make comes along, so
  93 that the gruesomeness of make and friends may die in oblivion.  (*)
  94
  95 (*) I personally would like to enter a Makefile as functional program,
  96 whose execution caches function results on the disk as files.  But I
  97 shan't bother you further with my vaporware thoughts..