On Thu, 26 Feb 2026 23:03:52 GMT, Erik Joelsson <[email protected]> wrote:

>> GNU Make 4.4.1 changed the behavior of the variable MAKEFLAGS. This is 
>> causing our makefiles to behave weirdly in certain situations. We need to 
>> check for certain options in MAKEFLAGS to adjust behavior, and the way we do 
>> it is not compatible with GNU Make 4.4.1. In the GNU Make manual, it's 
>> [documented how you should query MAKEFLAGS for 
>> options](https://www.gnu.org/software/make/manual/make.html#Testing-Flags) 
>> and this patch is applying this recommendation. With this patch, I can 
>> successfully run the failing examples given in the bug using 4.4.1. I have 
>> also verified that tab completion still works and that the output of `make 
>> -p -q` looks the same before and after.
>> 
>> Big thanks to Jaikiran who found the solution to this!
>
> Erik Joelsson has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Handle corner case with make 3.x

Just for some additional reference, this section in make documentation 
https://www.gnu.org/software/make/manual/make.html#Options_002fRecursion 
explains how the `MAKEFLAGS` variable gets composed:

> This variable is set up automatically by make to contain the flag letters 
> that make received. Thus, if you do ‘make -ks’ then MAKEFLAGS gets the value 
> ‘ks’. 
> ...
> The value of MAKEFLAGS is a possibly empty group of characters representing 
> single-letter options that take no argument, followed by a space and any 
> options that take arguments or which have long option names. If an option has 
> both single-letter and long options, the single-letter option is always 
> preferred. If there are no single-letter options on the command line, then 
> the value of MAKEFLAGS starts with a space.

So I think there are ways to be a bit more precise to check if the `p` or `q` 
short option was used when launching make. But even checking for "does the 
value of MAKEFLAGS start with a space character, if it does then there are no 
single letter option" doesn't seem straightforward in make (at least I couldn't 
find a standard text function for it 
https://www.gnu.org/software/make/manual/make.html#Text-Functions)

That same documentation has this additional detail:

> A similar variable MFLAGS exists also, for historical compatibility. It has 
> the same value as MAKEFLAGS except that it does not contain the command line 
> variable definitions, and it always begins with a hyphen unless it is empty 
> (MAKEFLAGS begins with a hyphen only when it begins with an option that has 
> no single-letter version, such as ‘--warn-undefined-variables’).
> ...
> If you want your makefiles to be compatible with old make programs, use this 
> technique; it will work fine with more modern make versions too. 

The semantics of `MFLAGS` seems promising in our context, because it is 
guaranteed not to contain the command line variables. So if nothing else works 
or if it gets too complicated dealing with `MAKEFLAGS`, then maybe we should 
use `MFLAGS` instead?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29942#issuecomment-3972575835

Reply via email to