Follow-up Comment #2, bug #62469 (project make):

> I'm confident a lot of makefiles do do this, and although it's not a good
idea I don't know that we want to break them.

i agree, that we don't want to break existing makefiles. i also think, that a
build system which relies on a MAKEFLAGS=<value> cli definition is already
broken.


> Also, unfortunately the POSIX spec is not very clear on this point but as
far as I can tell it's not _disallowed_ there which means that it might be a
violation of POSIX.

posix description of makeflags is quite complicated, but as far as i can
decipher it, this piece instructs make to ignore MAKEFLAGS=<value> cli
definition.

"Before the makefile(s) are read, all of the make utility command line macro
definitions (except the MAKEFLAGS macro or the SHELL macro) shall be added to
the environment of make.".

i tested 5 implementations of make.

These are the questions
q1. Does MAKEFLAGS=<value> makefile defn affect topmake behavior?
q2. Does MAKEFLAGS=<value> makefile defn affect submake behavior?
q3. Does MAKEFLAGS=<value> cli defn affect topmake behavior?
q4. Does MAKEFLAGS=<value> cli defn affect submake behavior?

Here are the answers

++++
               q1     q2      q3     q4
sun make       no     yes     no     no
svr4 make      no     yes     no     no
aix make       no     yes     no     no
bmake          no     no      no     no
gmake          yes    yes     yes    yes
----


bmake does not honor MAKEFLAGS=<value> defn in the makefile. Instead, bmake
honors .MAKEFLAGS: special target.


> I'll need to think about the best way forward.

i think we can either
1. Keep the current behavior intact and possibly add a warning to the manual
that cli MAKEFLAGS=<value> defn wipes out cli flags.
or
2. Ignore cli MAKEFLAGS=<value> defn. This is what the attached patch does.

i think, we should not legalize MAKEFLAGS=<value> cli definition and should
not add code to allow MAKEFLAGS=<value> cli definition to be merged with cli
flags.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62469>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/


Reply via email to