Date: Wed, 4 Aug 2004 17:01:20 +0200 (CEST) From: Harti Brandt <harti@freebsd.org> To: Ruslan Ermilov <ru@freebsd.org> Cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/usr.bin/make Makefile main.c nonints.h var.c Message-ID: <20040804163846.C96634@beagle.kn.op.dlr.de> In-Reply-To: <20040804143624.GA26422@ip.net.ua> References: <200408031856.i73IuV8c082723@repoman.freebsd.org> <20040804122057.V96634@beagle.kn.op.dlr.de> <20040804143624.GA26422@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Aug 2004, Ruslan Ermilov wrote: RE>On Wed, Aug 04, 2004 at 12:25:10PM +0200, Harti Brandt wrote: RE>[...] RE>> Note also that you cannot do 'cd /usr/src/usr.bin ; RE>> make SUBDIR="last leave"' anymore. RE>> RE>What do you mean? AFAIK, this never worked because SUBDIR RE>was put as an environment variable into sub-makes, and RE>{last,leave}/Makefile would be confused by thinking they RE>have a non-empty SUBDIR (and then the ${PROG}: target and RE>a subdir:: target from bsd.subdir.mk come to a conflict): Well, the example was bad. This idiom was used in the X ports to build parts of X only, for example, imake. RE> RE>$ /old/make SUBDIR="last leave" regress RE>===> last RE>"/usr/share/mk/bsd.subdir.mk", line 60: Inconsistent operator for last RE>make: fatal errors encountered -- cannot continue RE>*** Error code 1 RE> RE>Stop in /usr/src/usr.bin. RE>$ /new/make SUBDIR="last leave" regress RE>===> last RE>"/usr/share/mk/bsd.subdir.mk", line 60: Inconsistent operator for last RE>"/usr/share/mk/bsd.subdir.mk", line 66: warning: duplicate script for target "last" ignored RE>make: fatal errors encountered -- cannot continue RE>*** Error code 1 RE> RE>Stop in /usr/src/usr.bin. RE> RE>> AL>Does this also apply to environment variables (CFLAGS="foo bar" make)? RE>> RE>> No. Environment variables have lowest priority - command line variables RE>> and makefiles override them. But you should be able to say RE>> CFLAGS="foo bar" make -E CFLAGS to move up CFLAGS in the priority list. RE>> RE>Uh no. ``make CFLAGS="foo bar"'' won't *work* because CFLAGS+='s won't RE>DTRT, since command-line variables still take precedence over globals: RE> RE>$ cat makefile RE>FOO= foo RE>FOO+= bar RE>all: RE>.if ${FOO} != "foo bar" RE> @echo impossible RE>.endif RE>$ make FOO=ick RE>impossible This is the intented behaviour. 'Work' means, that CFLAGS gets passed to all sub-makes and will not be overridden there. This does not mean that this mechanism makes sense for CFLAGS. RE>This commit isn't changing much, and the change is really natural. RE>All it does it to ensure that once FOO is specified as a command RE>line variable, it stays the command-line type variable in sub-makes. RE>The other semantics is not touched. Well, you can say 'make CFLAGS=-O' and that will use -O (and only -O) in all sub-makes. This is different from previous behavious where -O was not passed to sub-makes. For CFLAGS this doesn't make much sense, because CFLAGS are usually modified in Makefiles for a good reason, but it should enable you to do 'make CC=icc' or 'make WARNS=9' or 'make COPTS=-O5' and be sure that is used by all sub-makes. (Note: this breaks i4b which uses COPTS to mean CFLAGS). Most, if not all, of our Makefiles are careful to use += or ?= to not clobber existing values, so this change does help more with makefiles from external sources that contain a big hierarchy of Makeflags each one containing OPTFLAGS= -O CC= gcc ... harti
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040804163846.C96634>