Date: Thu, 1 Jul 2004 01:10:26 GMT
From: John E Hein <jhein@timing.com>
To: freebsd-bugs@FreeBSD.org
Subject: Re: bin/68534: make(1) - ${.MAKEFLAGS} does not contain cmd line args
Message-ID: <200407010110.i611AQBO025520@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/68534; it has been noted by GNATS.
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407010110.i611AQBO025520>