stepmake/Documentation/out/automake.txt

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