Re: [O] Reloading uncompiled and testing from several git branches

[François Pinard]

Achim Gratz <address@hidden> writes:

> François Pinard writes:

>> Any Makefile which lists dependencies while expecting them to be
>> satisfied sequentially, one after another, is broken.  Make does not
>> (theoretically) guarantee the order, while in practice, all "make"
>> programs I know satisfy dependencies from left to right.

> Well, if you're going to pick nits: in this case, nothing is broken.
> It's known that we're going to use GNU make and that no parallel
> execution is taking place.

I did not follow these things in years, they might have changed.  At
some time in the past, GNU packages had to follow GNU standards.  We had
to write portable Makefiles, could not depend on GNU make, and could not
depend on the serial evaluation of dependencies.  Many users had things
like "MAKEFLAGS=-j4" in their environment, so it blindly applied to all
their builds.  Maintainers would not know that "no parallel execution is
taking place", because it was the installers, and not them, to decide.

GNU libc has been the first important GNU package which broke the rule
and started to require GNU make; it's true that the GNU libc maintainer
and the GNU make maintainer were the same guy.  I guess that GNU libc
was so late that Richard Stallman allowed that exception.  Now that
Linux exists, it is very frequent to see packages requiring GNU make,
and GNU standards are taken much more lightly than they used to be.

Looking at the GNU make documentation, I find something new to me:

   [If] .NOTPARALLEL is mentioned as a target, then this invocation of
   make will be run serially, even if the ‘-j’ option is given.  Any
   recursively invoked make command will still run recipes in parallel
   (unless its makefile also contains this target). Any prerequisites on
   this target are ignored.

So now, the maintainer may prohibit parallelism from his side, and while
I did not see that GNU make explicitly guarantees left to right
evaluation and execution, the above says "serially" without telling the
order.  I would be tempted to think that the GNU make documentation is
voluntarily silent on the matter, as we may not depend on it.

If you depend on the order, you depend on the implementation of Make,
not on its specifications.  That's why I use the work "broken".  All
this is academical, and not much important.  For a long while now, the
effort for correct Makefiles faded away; this cannot be repaired.

François