bin/68534: make(1) - ${.MAKEFLAGS} does not contain cmd line args

[John E Hein]

The following reply was made to PR bin/68534; it has been noted by GNATS.

From: John E Hein <jhein at timing.com>
To: Giorgos Keramidas <keramida at ceid.upatras.gr>
Cc: bug-followup at freebsd.org
Subject: Re: bin/68534: make(1) - ${.MAKEFLAGS} does not contain cmd line args
Date: Wed, 30 Jun 2004 19:06:22 -0600

 Giorgos Keramidas wrote at 03:37 +0300 on Jul  1, 2004:
  > The keyword is "may".  If you set .MAKEFLAGS in your Makefile or MAKEFLAGS in
  > the environment than make(1) *will* *pass* these to child processes (as the
  > value of MAKEFLAGS in the environment).
 
 I am aware of that feature, but that has nothing to do with passing
 along elements of the command line as the man page mentions.
 
 First, let me quote the section.
 
      .MAKEFLAGS
                 The environment variable MAKEFLAGS may contain anything that
                 may be specified on make's command line.  Its contents are
                 stored in make's .MAKEFLAGS variable.  Anything specified on
                 make's command line is appended to the .MAKEFLAGS variable
                 which is then entered into the environment as MAKEFLAGS for
                 all programs which make executes.
 
 I see the 'may'.  But the 3rd sentence seems more definitive.  At the
 least it's misleading.  But I still don't see any way to get anything
 specified on the command line into MAKEFLAGS (or .MAKEFLAGS).
 
 
  > Not setting MAKEFLAGS is not an error, but does not imply that something
  > related to make's invocation will get passed in the environment.
  > 
  > Here's an an example:
  > 
  > : giorgos at gothmog:/tmp/maketest$ cat Makefile
  > : SUBDIR= alpha
  > :
  > : .MAKEFLAGS=     WITHOUT_X11=YES
  > :
  > : all:
  > :         @echo "MFLAGS     : ${MFLAGS}"
  > :         @echo "MAKEFLAGS  : ${MAKEFLAGS}"
  > :         @echo ".MAKEFLAGS : ${.MAKEFLAGS}"
  > :
  > : .include <bsd.subdir.mk>
  > : giorgos at gothmog:/tmp/maketest$ cat alpha/Makefile
  > : all:
  > :         @echo "MFLAGS     : ${MFLAGS}"
  > :         @echo "MAKEFLAGS  : ${MAKEFLAGS}"
  > :         @echo ".MAKEFLAGS : ${.MAKEFLAGS}"
  > :
  > : giorgos at gothmog:/tmp/maketest$ make WITHOUT_X11=NO
  > : MFLAGS     :  WITHOUT_X11=YES
  > : MAKEFLAGS  : WITHOUT_X11=YES
  > : .MAKEFLAGS : WITHOUT_X11=YES
  > : ===> alpha
  > : MFLAGS     :
  > : MAKEFLAGS  : WITHOUT_X11=YES
  > : .MAKEFLAGS :
  > : giorgos at gothmog:/tmp/maketest$
  > 
  > Note how WITHOUT_X11=NO in the command line does not have any effect because
  > ./Makefile sets .MAKEFLAGS to something different.  But the correct value *is*
  > propagated as expected to alpha/Makefile.
 
 That's because the precedence order is: env vars, globals, command
 line, locals.  Setting .MAKEFLAGS in the Makefile puts WITHOUT_X11=YES
 in the env which overrides the command line setting of WITHOUT_X11=NO.
 
 And if you didn't set .MAKEFLAGS in the parent dir (try commenting it
 out), the subdir make (as well as the parent dir) would echo empty
 values for all three vars.
 
 I think the bug still stands (whether it's just unfortunate docs or
 not).
 
 
  > If there is a bug here it's in what is described in the manpage as:
  > 
  >      MFLAGS     A synonym for .MAKEFLAGS provided for backward compatibility.
  > 
  > which isn't quite true AFAICT, since MFLAGS includes the value of .MAKEFLAGS
  > when the latter is set but not vice versa.
 
 Agreed on that.  Separate bug.