Re: [Automake-ng] What’s Wrong With GNU make?

[Stefano Lattarini]

Hi Bob.

On 04/05/2012 03:18 AM, Bob Friesenhahn wrote:
> Quite by accident (Google hit) I ran across this paper which describes what
> is wrong with GNU make:
> 
>   http://www.conifersystems.com/whitepapers/gnu-make/
>
Note that most of the issues described there are not specific to GNU make,
but common to all make implementations, so that Automake (and its developers)
are already aware of them.

> While I would add more (different) grievances, the paper seems to be pretty
> accurate and describes many issues I had not thought of before.
>
That paper raises some interesting point, but is also overly nitpicking and
alarmist IMHO.

Some of the issues described there, as lack of "true parsing" and possible
interferences from the environment, exist for the shell as well, and sometimes
in a worse form too (I think that the shell redefines the very concept of
"weird parsing rules", and not for the better).

Few issues pointed out in the article are PEBKAC; e.g.:

  If you run two instances of make in the same directory tree at the same
  time, they will collide with one another when they try to build the same
  files.

or:

  If you edit and save a file in the middle of a make session, the results
  are unpredictable.

Some issues should be easily worked around, at least with GNU make (e.g., you
can disable the builtin rules, and I think we should do that in Automake-NG).
Some other issues could be mitigated if we get Automake-NG right (e.g., we
should make it easy and convenient to write non-recursive build system).

Some other behaviours labelled as "issues" are in fact *features*; for example:

  There is also a confusing distinction between the results of make FOO=1 vs.
  the results of export FOO=1 followed by make. In the former, a line in
  the makefile FOO = 0 will have no effect! Instead, you must write override
  FOO = 0.

or:

  There are two types of variable assignments in make. := evaluates its
  right-hand side immediately; = evaluates it later when the variable is
  referenced.

There are also valid points of course (see for example the sub-sections on
"Last-Modified Timestamps", "Command Line Dependencies" or "After a Failed
or Cancelled Build"), but these have always been well-known.

> Presumably Automake NG will try to work-around many of these shortcomings
> of GNU make even though it is based on GNU make.
>
Automake-NG should try to work around *bugs* in GNU make, yes, but not around
its design characteristics (even where they're flawed and suboptimal).  That
seems unwarranted, fragile, and doomed to failure.  If we want a better model
for our build system, we should get a *new* build system (as you said below).
But that's overly ambition FTM I think; a better first step is to reduce the
clutter of the GNU build system by requiring GNU make and stopping catering to
bugs/limitation in seldom used, fringe make implementations.  What we learn
from this experience could later be used to conceive or evaluate a more modern
and "correct" build system, if we still think that's warranted.

> A proper fix would require improvements to GNU make itself,
>
An improvement I'd like to see would be the addition of conjunction/disjunction
for conditionals.  Of course, Automake-NG will not be able to take advantage of
them right away, because it will have to work with at least GNU make 3.81.

> or even a new build tool.
>
Something like this perhaps: <http://gittup.org/tup/> ?

Thanks,
  Stefano