--- /dev/null
+article(Automake -- Urgh!)(HWN and JCN)()
+
+sect(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 system. We focus on Automake, but of
+course writing complex file(Makefile.in)s without generating them
+automatically is an even more deadly sin in our opinion.
+
+
+sect(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-completed" features. However, file(make)
+itself is broken, and any tool built on top of file(make) is broken as well.
+
+
+sect(Irritations)
+
+We'll start with the superficial irritations first:
+itemize(
+it() 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.
+
+
+it() Automake tries to cater for every taste of file(make). But anyone
+who does more than the trivial code(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.
+
+
+it()
+Support for filetypes in built in to Automake, and cannot 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 TeX() 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.
+
+it() Dependency handling is unreliable in our experience. On
+several occasions we had unexplainable errors, that went away after
+doing a code(make distclean), and recompile.
+
+it() It is slower, much slower than a tailored solution. This
+diffence in speed can be as large as 800%. (On JCNs machine a
+code(make dist) takes 17 minutes in stead of 2) for every distribution
+made; this constitutes 45 minutes of irritation on an average hacking-night.
+
+it() For a large project, a specialised file(Makefile) system costs
+relatively little extra effort. The extra effort pays itself back in
+speed and control.
+
+it() The file(Makefile)s, file(Makefile.in)s, 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.) )
+
+sect(Fundamental problems)
+
+Many of the fundamental problems can be traced back to flaws in make:
+
+itemize(
+it() make is not standardised. The only decent implementation is
+GNU make, and GNU make is not widespread enough to require GNU make for
+compiling GNU tools.
+
+it() make does not have enough meta-ness: one cannot manipulate
+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.)
+
+
+
+it() code(VPATH) is a broken concept: programs should not try to be
+intelligent on their own; being intelligent is something 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 versions for
+maintainer and user.
+
+
+sect(Conclusions)
+
+We could be called `cheap' for complaining about the above points,
+while not even filing decent bugreports. The reality 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 functional program,
+whose execution caches function results on the disk as files. But I
+shan't bother you further with my vaporware thoughts..
projects / lilypond.git / commitdiff