[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Regression caused by Commit: 5bd7ad2b225b ("Preserve the real value
Re: Regression caused by Commit: 5bd7ad2b225b ("Preserve the real value of -jN in MAKEFLAGS using jobserver.")
Mon, 30 Oct 2017 17:22:19 -0400
On Tue, 2017-10-31 at 07:39 +1100, NeilBrown wrote:
> On Mon, Oct 30 2017, Tim Murphy wrote:
> > For my money -j is always a top-level setting. To have it per makefile
> > and then let makefiles depend on that behaviour would open the door to lots
> > of scary bugs.
I don't see what scary bugs we might have; I've seen issues where
makefiles not intended to be used with -j will not work properly with
-j, but I'm not sure I've ever seen an issue with a makefile intended
to work with -j that fails when run without it, or with a different
> I'm beginning to agree with this perspective.
> The "-j" setting is not really a function of the code, it is a
> function of the hardware that make is being run on.
> So I should set MAKEFLAGS=-j8 in my environment instead of if the
I definitely agree that's best-practice. You could also use the
(newer) GNUMAKEFLAGS environment variable which will ensure only GNU
make sees the value (in case you run other versions of make).
> Maybe we just need to change the documentation...
I definitely agree that setting -j inside a makefile is not a good
idea, just like adding -k or -d or whatever.
However people do it and it used to work.
The question is what should make do when it happens? Silently ignoring
it as now doesn't seem like a winning alternative.
If we see -j in a makefile setting of MAKEFLAGS, we could:
1. Always silently ignore it (today's behavior).
2. Always print a message then ignore it.
3. Treat it the same way as a recipe with $(MAKE) -j: that is, start a
new jobserver group for this sub-make (and print a message if we're
already part of a different jobserver group).
Personally I lean towards #3, even if it does allow people to do