Date: Thu, 18 Apr 2002 17:31:01 +0300 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: Alex Semenyaka <alexs@ratmir.ru> Cc: Matthew Emmerton <matt@gsicomp.on.ca>, freebsd-hackers@FreeBSD.ORG Subject: Re: make(1) command-line variables Message-ID: <20020418143101.GC70982@sunbay.com> In-Reply-To: <20020413171226.GD18143@snark.ratmir.ru> References: <20020413141834.GA16339@snark.ratmir.ru> <001901c1e2fe$2b64c740$1200a8c0@gsicomp.on.ca> <20020413171226.GD18143@snark.ratmir.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Sat, Apr 13, 2002 at 09:12:26PM +0400, Alex Semenyaka wrote:
> Hi there,
>
> On Sat, Apr 13, 2002 at 11:16:20AM -0400, Matthew Emmerton wrote:
> >> .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.
> >>
> >> That is wrong, .MAKEFLAGS does not contain anything.
> > It won't contain anything unless you set MAKEFLAGS in the calling
> > environment.
>
> Argh! Sorry, that was my fault: MAKEFLASG (env var) will be copied to
> .MAKEFLAGS (make's var) and it can contain anything. Absolutely correct -
> here. But I've asked a little bit different question. Suppose, I wrote
>
> make VAR=VAL # .MAKEFLAGS is empty
>
> There is no way to trace this parameter inside Makefile. I mean you cannot
> put something in your Makefile that will tell you 'for this build we have
> value VAL assined to the variable VAR'. However you can easily do such
> things with definitions of that style:
>
> make -DVAR # .MAKEFLAGS is '-D VAR'
>
> which logically should be equivalent to
>
> make VAR=1 # .MAKEFLAGS is empty again
>
> Moreover, in the last case there is NO ANY MAKE'S VARIABLE containing VAR, see:
>
> bash-2.05a$ make -DUUU -V .MAKEFLAGS
> -D UUU -V .MAKEFLAGS
> bash-2.05a$ make UUU=1 -V .MAKEFLAGS
> -V .MAKEFLAGS
> bash-2.05a$ make UUU=1 -dv -r | grep UUU
> bash-2.05a$
>
> Hope now I was more careful and clear... But sure I might miss sothing
> again, so will wait for replys.
>
Heh, was looking at this NetBSD commitlog today looking for another
thing. They apparently have this bug fixed as well, in the step 3
below:
: revision 1.67
: date: 2001/06/01 20:33:37; author: sjg; state: Exp; lines: +42 -6
:
: A number of semi-related changes.
: 1. make -dx turns on DEBUG_SHELL which causes sh -x to be used where
: possible.
: 2. PrintOnError() is now called when make is stopping due to an error.
: This routine reports the curdir and the value of any variables listed
: in MAKE_PRINT_VAR_ON_ERROR.
: 3. Variables set via command line, are propagated to child-makes via
: MAKEFLAGS. This behaviour appears to be necessary for POSIX (according
: to the GNU folk anyway).
: 4. Do not reset MAKEFILE when reading ".depend" as this rather eliminates the
: usefulness of ${MAKEFILE}.
: 5. Added ${.newline} as a simple means of being able to include \n in the
: result of a :@ loop expansion.
: 6. Set ${MAKE_VERSION} if defined. Need to come up with a useful value.
:
: Reviewed: christos
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
ru@sunbay.com Sunbay Software AG,
ru@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE8vtilUkv4P6juNwoRAisPAJ9jVOUgK3ToBSDyObdruNwfYFUC1gCeITfM
fjQX52aaNeO+I6eEsn7p/lo=
=xL/k
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020418143101.GC70982>