Re: Make's assumption that files it does not create do not change

[Kaz Kylheku]

On 2022-04-12 08:18, Sébastien Hinderer wrote:
> Dear all,
>
> David Allsopp (@dra27 on GitHub), in Cc, has submitted the following
> pull request on the OCaml repository:
>
> https://github.com/ocaml/ocaml/pull/11180

> We are also wondering whether such situations wouldn't deserve a few
> words of explanation in the manual (we believe this behaviour is
> currently not explicitly documented).

The GNU Make documentation has a section on empty recipes, but doesn't
mention anything about that having the power to resolve parallel build
problems.

It does point out that an empty recipe will prevent that target from
getting a recipe implicitly from some pattern rule or whatever.

For instance, if we say foo.o: foo.c ; then any implicit rule
for building a .o from a .c is suppressed for foo.o: the empty rule
applies. If the implicit rule did something undesirable, then that
could somehow make a problem appear to go away. Say that foo.o
is some ready-made object coming from some other build system, 
accompanied
by foo.c just for reference. This empty rule will prevent our Makefile
from trying to build it; but we can still have it in OBJS for linking.

Anyway, will find that you get excellent help in help-make@gnu.org if 
you
can produce a MCVE ("minimal complete verifiable example") that
demonstrates the issue.

Speaking from my personal opinion/experience only, a good way to
deal with this kind of situation (poorly understood parallel
build issue) is to pull the brakes on parallel builds entirely:
add a .NOTPARALLEL: target near the top of the Makefile.
Parallelism is an optimization; but correctness takes precedence over 
speed.

Publish the .NOTPARALLEL change, and then you can treat this as a
low-priority issue, taking the time to holistically revise the
Makefile to have clear parallel semantics, so the NOTPARALLEL
can be removed.

> Please, if you wish to react to this e-mail, we would appreciate if you
> could do so on GitHub rather than here

Did you just send a e-mail to a GNU mailing list, asking for discussion 
to be
continued in a proprietary walled garden?

That's funny.