On Tue, Nov 29, 2022 at 1:22 AM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > Kbuild is already having an issue in the -s detection. > $ export MAKEFLAGS=-I/usr/local/mk > or > $ export MAKEFLAGS=-Orecurse i am not concerned about these use cases. This code in question fails to handle the use case of MAKEFALGS in env and apparently this does not bother anyone, otherwise this code would already be fixed. My concern is that the change, that we introduced to make, won't cause a regression to those of us who specify -s, once the users migrate to the new make. However, the fix will help the MAKEFLAGS-in-env use case, as well. > Commit 77881d228103 ("Ensure that MAKEFLAGS is set when invoking $(shell ...)") > is the commit that caused a change. The whole sequence of events is the following 1. commit 98da874c43035a490cdca81331724f233a3d0c9a [SV 10593] Export variables to $(shell ...) commands This allowed make variables to be exported to $(shell) at parse time. 2. Then a user opened https://savannah.gnu.org/bugs/?63347 and (correctly) argued that the behavior is inconsistent. The inconsistency was caused by MAKEFLAGS lacking command line variable definitions until build time. 3. commit dc2d963989b96161472b2cd38cef5d1f4851ea34 [SV 63347] Always add command line variable assignments to MAKEFLAGS This adds command line variable definitions to MAKEFLAGS at parse time. > Please send v2 with $(firstword) and updated commit log. > Also, add this tag: > Link: https://lists.gnu.org/archive/html/bug-make/2022-11/msg00190.html Done. regards, Dmitry