Re: odd -J complaint from make on netbsd-11

["Simon J. Gerraty" <sjg%crufty.net@localhost>]

On Wed, 04 Feb 2026 11:02:02 -0500, Greg Troxel writes:
>I think where we are is:
>
>  double stack trace bug fixed in current, not pulled up
>
>  agreement in concept that it would be nice if $(MAKE) etc in a
>  variable which is in a rule is like .MAKE, but nothing has been
>  committed (not a complaint)

I started a patch to do this - mostly to do the optimization I
mentioned of meta_oodate detecting progname or "make" while examining
the expanded commands.  This resulted in changed result to one or two
tests that I don't fully grok so I reached out to Roland.

Actually it occurs to me now, that if GNode_AddCommand checks the
expanded command then the above is unnecessary.

We'll still have the test result changes to deal with though, as there
should be fewer false positives etc.

>I have one remaining confusion: is the complaint from the parent make
>that it is passing -J to a child, or is in from the child?   If the

It is from the child - it received -J 15,16 or similar and the specified
descriptors are not valid.  We delay the warning - which is unnecessary
if other options or makefile put us in compat mode.

>parent knows it is invoking a submake, why does it object that it's not
>marked, when it attempts to mark it automatically?

Unless the target is marked OP_SUBMAKE, parent make has no clue that it
is invoking make, but -J 15,16 will be in .MAKEFLAGS

--sjg