From jhein@timing.com  Wed Jun 30 23:36:17 2004
Return-Path: <jhein@timing.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 7017C16A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 30 Jun 2004 23:36:17 +0000 (GMT)
Received: from Daffy.timing.com (mx1.timing.com [206.168.13.218])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 2B68443D1D
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 30 Jun 2004 23:36:17 +0000 (GMT)
	(envelope-from jhein@timing.com)
Received: from gromit.timing.com (gromit.timing.com [206.168.13.209])
	by Daffy.timing.com (8.12.8p2/8.12.8) with ESMTP id i5UNa3vO037171
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 30 Jun 2004 17:36:03 -0600 (MDT)
	(envelope-from jhein@timing.com)
Received: from gromit.timing.com (localhost [127.0.0.1])
	by gromit.timing.com (8.12.11/8.12.11) with ESMTP id i5UNa2C8029696;
	Wed, 30 Jun 2004 17:36:02 -0600 (MDT)
	(envelope-from jhein@gromit.timing.com)
Received: (from jhein@localhost)
	by gromit.timing.com (8.12.11/8.12.11/Submit) id i5UNa2cc029695;
	Wed, 30 Jun 2004 17:36:02 -0600 (MDT)
	(envelope-from jhein)
Message-Id: <200406302336.i5UNa2cc029695@gromit.timing.com>
Date: Wed, 30 Jun 2004 17:36:02 -0600 (MDT)
From: "John E. Hein" <jhein@timing.com>
Reply-To: "John E. Hein" <jhein@timing.com>
To: FreeBSD-gnats-submit@freebsd.org
Subject: make(1) - ${.MAKEFLAGS} does not contain cmd line args
X-Send-Pr-Version: 3.113
X-GNATS-Notify: harti

>Number:         68534
>Category:       bin
>Synopsis:       make(1) - ${.MAKEFLAGS} does not contain cmd line args
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 30 23:40:16 GMT 2004
>Closed-Date:    Thu Jul 01 08:06:13 GMT 2004
>Last-Modified:  Thu Jul  1 12:40:18 GMT 2004
>Originator:     John E. Hein
>Release:        FreeBSD 4.10-RELEASE i386
>Organization:
Timing Solutions
>Environment:
System: FreeBSD gromit.timing.com 4.10-RELEASE FreeBSD 4.10-RELEASE #1: Wed Jun 23 10:12:32 MDT 2004 jhein@gromit.timing.com:/usr/pub/jhein/obj/usr/pub/jhein/src/sys/GROMIT i386

	at least 4.3, 4.10 and 5.2-CURRENT (as of May 2004)

>Description:
	MAKEFLAGS env variable & .MAKEFLAGS make variable does not contain
    command line args as specified in make(1).


>How-To-Repeat:

$ cat Makefile
.PHONY: x
x:
    @echo MAKEFLAGS: ${MAKEFLAGS}
    @echo MFLAGS: ${MFLAGS}
    @echo .MAKEFLAGS: ${.MAKEFLAGS}
$ make FOO=1
MAKEFLAGS:
MFLAGS:
.MAKEFLAGS:


>Fix:

	1) remove erroneous documentation
	 or
	2) fix make to add args to ${.MAKEFLAGS} make var
	   (I have no patch at the moment)

	(#2 preferred)
>Release-Note:
>Audit-Trail:

From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: "John E. Hein" <jhein@timing.com>
Cc: bug-followup@freebsd.org
Subject: Re: bin/68534: make(1) - ${.MAKEFLAGS} does not contain cmd line args
Date: Thu, 1 Jul 2004 03:37:25 +0300

 On 2004-06-30 17:36, "John E. Hein" <jhein@timing.com> wrote:
 > MAKEFLAGS env variable & .MAKEFLAGS make variable does not contain command
 > line args as specified in make(1).
 
 This is not a bug.
 
 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).
 
 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@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@gothmog:/tmp/maketest$ cat alpha/Makefile
 : all:
 :         @echo "MFLAGS     : ${MFLAGS}"
 :         @echo "MAKEFLAGS  : ${MAKEFLAGS}"
 :         @echo ".MAKEFLAGS : ${.MAKEFLAGS}"
 :
 : giorgos@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@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.
 
 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.
 
 - Giorgos
 

From: John E Hein <jhein@timing.com>
To: Giorgos Keramidas <keramida@ceid.upatras.gr>
Cc: bug-followup@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@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@gothmog:/tmp/maketest$ cat alpha/Makefile
  > : all:
  > :         @echo "MFLAGS     : ${MFLAGS}"
  > :         @echo "MAKEFLAGS  : ${MAKEFLAGS}"
  > :         @echo ".MAKEFLAGS : ${.MAKEFLAGS}"
  > :
  > : giorgos@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@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.

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

 This is interesting env var precedence weirdness...
 
 $ cat Makefile
 FOO?=0
 X?=0
 .PHONY: x
 x:
 	@echo MAKEFLAGS: ${MAKEFLAGS}
 	@echo .MAKEFLAGS: ${.MAKEFLAGS}
 	@echo FOO: ${FOO}
 .if $X != 1
 	make X=1
 .endif
 
 $ env FOO=1 MAKEFLAGS=FOO=3 make FOO=2
 MAKEFLAGS: FOO=3
 .MAKEFLAGS:
 FOO: 2
 make X=1
 MAKEFLAGS: FOO=3
 .MAKEFLAGS:
 FOO: 3
 
 $ env FOO=1 make FOO=2
 MAKEFLAGS:
 .MAKEFLAGS:
 FOO: 2
 make X=1
 MAKEFLAGS:
 .MAKEFLAGS:
 FOO: 2
 
 
 In the first case FOO=3 is inserted in the environment by make via
 MAKEFLAGS.
 
 In the second case FOO=1 is inserted in the environment in a more
 generic way.
 
 Why does FOO=2 (the cmd line variable) override FOO in the environment
 in the first case, but not the second?  I'm going to have a look in
 the source.
 
 And finally...
 
 $ env FOO=1 make -E FOO FOO=2
 MAKEFLAGS: -E FOO
 .MAKEFLAGS: -E FOO
 FOO: 2
 make X=1
 MAKEFLAGS: -E FOO
 .MAKEFLAGS: -E FOO
 FOO: 2
 
 But that is as expected.  It's case 2 that puzzles me.
 
 Whoa, wait a second.  There's some stuff from the command line
 in MAKEFLAGS now.
 
 So I guess the bug is that only CERTAIN things from the command
 line show up in MAKEFLAGS>
State-Changed-From-To: open->closed 
State-Changed-By: ru 
State-Changed-When: Thu Jul 1 08:05:19 GMT 2004 
State-Changed-Why:  
Duplicate of PR standards/57295. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=68534 

From: Ruslan Ermilov <ru@FreeBSD.org>
To: John E Hein <jhein@timing.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/68534: make(1) - ${.MAKEFLAGS} does not contain cmd line args
Date: Thu, 1 Jul 2004 11:33:21 +0300

 On Thu, Jul 01, 2004 at 01:10:26AM +0000, John E Hein wrote:
 >  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).
 >  
 Only variable=value are not stored in .MAKEFLAGS at the moment,
 everything else does.  With this command line,
 
 	make -DFOO BAR=2 -B -j2
 
 MAKEFLAGS will be ``-D FOO -B -j 2''.
 
 See the PR which this one duplicates, which has a patch to store
 command line variable assignments in .MAKEFLAGS.
 
 
 Cheers,
 -- 
 Ruslan Ermilov
 ru@FreeBSD.org
 FreeBSD committer

From: Ruslan Ermilov <ru@FreeBSD.org>
To: John E Hein <jhein@timing.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/68534: make(1) - ${.MAKEFLAGS} does not contain cmd line args
Date: Thu, 1 Jul 2004 12:05:57 +0300

 On Thu, Jul 01, 2004 at 01:30:10AM +0000, John E Hein wrote:
 > 
 >  This is interesting env var precedence weirdness...
 >  
 >  $ cat Makefile
 >  FOO?=0
 >  X?=0
 >  .PHONY: x
 >  x:
 >  	@echo MAKEFLAGS: ${MAKEFLAGS}
 >  	@echo .MAKEFLAGS: ${.MAKEFLAGS}
 >  	@echo FOO: ${FOO}
 >  .if $X != 1
 >  	make X=1
 >  .endif
 >  
 >  $ env FOO=1 MAKEFLAGS=FOO=3 make FOO=2
 >  MAKEFLAGS: FOO=3
 >  .MAKEFLAGS:
 >  FOO: 2
 > 
 As documented, MAKEFLAGS value (FOO=3) is parsed just like
 if it were a part of the command line, so this is equivalent
 to ``env FOO=1 make FOO=3 FOO=2'', so `2' is printed.
 
 >  make X=1
 >  MAKEFLAGS: FOO=3
 >  .MAKEFLAGS:
 >  FOO: 3
 >  
 Now, we just call ``make'' with FOO=2 and MAKEFLAGS=FOO=3 in
 environment.  New make parses MAKEFLAGS, so this becomes
 equivalent to ``env FOO=2 make FOO=3'', so `3' is printed.
 
 >  $ env FOO=1 make FOO=2
 >  MAKEFLAGS:
 >  .MAKEFLAGS:
 >  FOO: 2
 > 
 Here, `2' is printed, and FOO is entered into environment
 with value 2.
 
 >  make X=1
 >  MAKEFLAGS:
 >  .MAKEFLAGS:
 >  FOO: 2
 >  
 Here, ${FOO} is fetched from the environment with value 2.
 
 >  In the first case FOO=3 is inserted in the environment by make via
 >  MAKEFLAGS.
 >  
 Not quite.  What's in environment is FOO=2 and MAKEFLAGS=FOO=3
 (see above).
 
 >  In the second case FOO=1 is inserted in the environment in a more
 >  generic way.
 >  
 And then FOO=2 causes FOO in environment to be reset to `2'.
 
 >  Why does FOO=2 (the cmd line variable) override FOO in the environment
 >  in the first case, but not the second?  I'm going to have a look in
 >  the source.
 >  
 I don't quite understand what you're asking, but I hope my
 explanations answer this.  ;)
 
 >  And finally...
 >  
 >  $ env FOO=1 make -E FOO FOO=2
 >  MAKEFLAGS: -E FOO
 >  .MAKEFLAGS: -E FOO
 >  FOO: 2
 > 
 Here, you say to prefer environment variable FOO over global
 FOO (there's no global FOO, FOO?=0).  Then, FOO=2 is parsed
 and FOO in environment is re-assigned the value of 2, and
 it's what gets printed.
 
 >  make X=1
 >  MAKEFLAGS: -E FOO
 >  .MAKEFLAGS: -E FOO
 >  FOO: 2
 >  
 Here, we just print FOO from environment, which is `2'.
 
 >  Whoa, wait a second.  There's some stuff from the command line
 >  in MAKEFLAGS now.
 >  
 Like I said in another email, only variable=value is not saved
 in MAKEFLAGS.
 
 
 Cheers,
 -- 
 Ruslan Ermilov
 ru@FreeBSD.org
 FreeBSD committer

From: John E Hein <jhein@timing.com>
To: Ruslan Ermilov <ru@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/68534: make(1) - ${.MAKEFLAGS} does not contain cmd line args
Date: Thu, 1 Jul 2004 06:39:14 -0600

 Ruslan Ermilov wrote at 12:05 +0300 on Jul  1, 2004:
  > On Thu, Jul 01, 2004 at 01:30:10AM +0000, John E Hein wrote:
  > > 
  > >  This is interesting env var precedence weirdness...
 
 I got it now.  My precedence interpretation was backwards.  I was
 going: env overrides global overrides command line overrides local.
 It is, of course, the opposite.
 
 +1 for the patch in standards/57295 (after ports fixes verified).
 
 I'll have to check our product builds with that patch to make sure
 they work.  Is that patch up to date or is there another one floating
 around in p4?  I think we have one or more hacks using the .MAKEFLAGS
 target which we'll be able to remove after make is patched.
 
 Thanks for the explanations, Ruslan.
>Unformatted:
