Re: proposal to fork the build-tools projects

[Tom Tromey]

[ back to automake for this one ]

>>>>> "Tom" == Tom Lord <address@hidden> writes:

Tom> Also in defence of the `sh + make' approach:

Tom> GNU make can do lots of useful globbing and set manipulation of file
Tom> lists.

Tom> If you do things right, your Makefiles don't need to contain
Tom> specific filenames at all, and you don't need to edit any
Tom> Makefiles as you add, delete, or rename files -- you just move
Tom> things around more or less freely, and the build-process catches
Tom> up more or less automatically.

Long-time automake readers already know I'm strongly against this sort
of structuring.  This yields Makefiles which are fragile and
undependable.  For instance, if you create a temporary file with a
"source-like" name in the source tree, then the build fails.

I could add globbing to automake.  I've always resisted it for the
reasons above.  (There was a brief time where I vacillated, if you
read the archives fully.  But that era is past.)

Tom> I'm therefore not sure it's a really high priority to bother: GNU
Tom> make, for example, seems like a quite tractable little program in
Tom> an implementation that's well suited to make run really fast (and
Tom> that can be compiled in a very minimal environment).

All implementations of make, including GNU make, are missing features
that are helpful when scaling up to larger builds.  They are also
missing features which help dependability and reproducibility of
builds.  In some cases, like using timestamps instead of signatures,
this change is impossible to implement in make -- switching to
signatures would break every Makefile that uses a stamp file.

For this and other reasons I think that make must go.

Tom