From the GNU make 3.82 release announcement (2010):
The ‘define’ make directive now allows a variable assignment operator after the variable name, to allow for simple, conditional, or appending multi-line variable assignment.
macOS ships with 3.81 (2006). This caused the multiprocess config options to be ignored.
Fixes #32068
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32070.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | ryanofsky |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
From the GNU make 3.82 release announcement:
* The 'define' make directive now allows a variable assignment operator
after the variable name, to allow for simple, conditional, or appending
multi-line variable assignment.
macOS ships with 3.81. This caused the multiprocess config options
to be ignored.
Fixes #32068
Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
Code review ACK 9157d9e449870851ef455e077249ac46fc2df24c. This is a pretty unusual bug and I don’t understand how it wasn’t causing any errors with make 3.81, just causing the flags to be ignored.
(Another case where there was a problem with make 3.81 was https://github.com/bitcoin-core/libmultiprocess/issues/139 / #31741 (comment))
I don’t understand how it wasn’t causing any errors with make 3.81
I probably haven’t recently used the depends build to test multiprocess on my development machine. I would either use my locally install libmultiprocess or a (cross-compiled) Guix build.
And macOS native CI doesn’t build depends with multiprocess.
This is a pretty unusual bug and I don’t understand how it wasn’t causing any errors with make 3.81, just causing the flags to be ignored.
In light of silent failures, it would be better to rule out this class of bug completely. Otherwise, a new instance will be added in the future, or will already exist somewhere in the code.
I am not sure why reviewers should spend time on supporting build tools that were released about 20 years ago. So rejecting such a build tool early with a failure seems more appropriate and will likely save developer, reviewer and user time debugging silent failures.
@maflcko I’m fine with introducing a minimum GNU make version, as long as we actually check the version (otherwise we’re back to silent failures).
But note that I run the stock macOS GNU make all the time, as do many other devs. So new issues are likely to be caught during review, though they’ll still waste time debugging.
But note that I run the stock macOS GNU make all the time, as do many other devs. So new issues are likely to be caught during review, though they’ll still waste time debugging.
FWIW, the stock macOS Make has other issues.
Is there a way we can pick up a modern homebrew version of make without forcing macOS devs and users to change their default make? (and without the use of env variables)
I imagine something like that:
0gmake -C depends -j 4