Re: Regression caused by Commit: 5bd7ad2b225b ("Preserve the real value of -jN in MAKEFLAGS using jobserver.")

[Paul Smith]

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

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

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