18 2: What's wrong with Automake?
20 4: Fundamental problems
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.
35 2: What's wrong with Automake?
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.
48 We'll start with the superficial irritations first:
50 o there is no intrinsic support for wildcarding; Adding
51 support for wildcarding adds yet another layer to a
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.
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
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.
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
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.
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.
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.
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.
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.
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
116 4: Fundamental problems
119 Many of the fundamental problems can be traced back to flaws
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.
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.
132 (In our tailor made compilation system, we worked
133 around this non-feature by using generic include files
136 as a stopgap function call.)
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
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.
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
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.
166 We hope that some day a better replacement for make comes
167 along, so that the gruesomeness of make and friends may die
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