Re: 4.4.1 breaks recursive invocation with --print-directory [when adding to MAKEFLAGS]

[Paul Smith]

On Tue, 2023-02-28 at 22:34 -0600, Satish Balay via Bug reports and
discussion for GNU make wrote:
> And the reason we use the order '-j8 ${MAKEFLAGS}' is so that we have
> the following behavior':
> 
> - invoking 'make' defaults to using a default of '-j8'
> - invoking 'make -j4' gives: '-j8 -j4' - i.e ability to override this
> (pre-set) default [when needed].

I'm pretty confident that this has never worked.

When the initial, top-level make is invoked with -jN it creates the
jobserver and it seeds the jobserver with N tokens to be used across
all the sub-makes.  It then passes details about the jobserver, in
MAKEFLAGS, to all sub-makes.

Any sub-make that sees the jobserver details in MAKEFLAGS will use that
same jobserver and when they want to run a job they will retrieve a
token from the jobserver.  If they get one they run the job.  Otherwise
they wait until one is available.  They pay no attention whatsoever to
the value of N in any -jN argument that they receive and they don't
keep track of the number of jobs they are currently running and compare
it to this value.

It is definitely not the case that you can limit (or increase) a
specific sub-make to have a different number of jobserver tokens.  The
only way you can change this is to create a NEW jobserver, with its own
set of tokens that are completely distinct from the original jobserver.
And the only way to do that is to _remove_ the jobserver details from
MAKEFLAGS; here you are explicitly _preserving_ the jobserver details
in MAKEFLAGS.

In fact, in earlier versions of GNU make we didn't even pass the -j
option to sub-makes at all; now we do but it's really only there so
people can query the MAKEFLAGS variable to see how many tokens were
available.  GNU Make doesn't pay any attention to this value, in a sub-
make.

I'm not saying that there isn't an issue here related to how we are now
handling MAKEFLAGS.  But, the particular use case, at least as you've
described it here, has never worked the way you expect.