bugmake - Bugs: bug #62469, Make honors...

 
 

bug #62469: Make honors MAKEFLAGS=<value> definition on the command line.

Submitter:  Dmitry Goncharov <dgoncharov>
Submitted:  Mon 16 May 2022 02:12:20 AM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  4.4 Operating System:  None
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 26 May 2022 02:08:38 AM UTC, comment #2: 


> 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.

Dmitry Goncharov <dgoncharov>
Mon 23 May 2022 01:51:38 PM UTC, comment #1: 

I do agree that the current behavior is not correct, but I'm not sure that disallowing MAKEFLAGS to be set on the command line is the right answer.  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.

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.

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

It may be that we simply have to make the command line options idempotent and be able throw away and re-parse them at any time.  I don't know how far away from that we are today.

Paul D. Smith <psmith>
Group administrator
Mon 16 May 2022 02:12:20 AM UTC, original submission:  

Make honors MAKEFLAGS=<value> definition on the command line.

Such command line definition wipes out command line switches from the resultant MAKEFLAGS definition, even though the command line switches are active.

In this example switch -d is active, but the value of MAKEFLAGS in make's memory is 'r'.


$ cat makefile
$(info      at parse time MAKEFLAGS="$(MAKEFLAGS)")
all:;$(info    in a recipe MAKEFLAGS="$(MAKEFLAGS)")
$ /usr/bin/make -d MAKEFLAGS=r
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'makefile'...
at parse time MAKEFLAGS="r"
Updating makefiles....
 Considering target file 'makefile'.
  Looking for an implicit rule for 'makefile'.
  No implicit rule found for 'makefile'.
  Finished prerequisites of target file 'makefile'.
 No need to remake target 'makefile'.
Updating goal targets....
Considering target file 'all'.
 File 'all' does not exist.
 Finished prerequisites of target file 'all'.
Must remake target 'all'.
in a recipe MAKEFLAGS="r"
Successfully remade target file 'all'.
make: 'all' is up to date.


Parent make then passes this incorrect value of MAKEFLAGS to each recursive child make.

The manual already describes that MAKEFLAGS should only be specified in makefile or in the environment. E.g. appendix a says
"MAKEFLAGS

    The flags given to make. You can set this in the environment or a makefile to set flags."

and

In 5.7.3 the manual says
"If you do not want to pass the other flags down, you must change the value of MAKEFLAGS, like this:

subsystem:
        cd subdir && $(MAKE) MAKEFLAGS="

The manual does not explicitly describe what happens when MAKEFLAGS=<value> is defined on the command line.

This patch adds a piece of code which causes make to ignore MAKEFLAGS=<value> command line argument and print a warning.
This patch also adds a piece of documentation to the manual to explicitly prohibit MAKEFLAGS=<value> arguments.

Dmitry Goncharov <dgoncharov>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53206:  sv62469_doc.diff added by dgoncharov (2KiB - text/x-patch)
file #53207:  sv62469_test.diff added by dgoncharov (3KiB - text/x-patch)
file #53208:  sv62469_fix.diff added by dgoncharov (1KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by dgoncharov (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-05-16 dgoncharov Attached File- Added sv62469_doc.diff, #53206
        Attached File- Added sv62469_test.diff, #53207
        Attached File- Added sv62469_fix.diff, #53208

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code