[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kaz Kylheku
Subject: Re: Make's assumption that files it does not create do not change
Date: Tue, 12 Apr 2022 11:54:31 -0700
User-agent: Roundcube Webmail/1.4.13

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:

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

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 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]