Re: Make's assumption that files it does not create do not change
Kaz Kylheku <[email protected]>
| Newsgroups | gmane.comp.gnu.make.general |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] 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.