Paul,
Thank you for the prompt pointer to this information.
I have been experimenting with the private & export keywords, but still I
encounter an odd behavior related to the ordering of two rules with
target-specific variables and a single shared prerequisite. For example, the
example below order_1 and order_2 result in different behaviors in the
execution of the prerequisite target, one of which is always guaranteed to be
"wrong" from the perspective of the other target which has defined a different
value for the target-specific variable. I believe this occurs because the body
of the prerequisite must only be executed once. Can one determine that the
prerequisite as previously built doesn't meet the requirements of the current
target? Is there any way to detect the difference in the variable set arriving
at the prerequisite via both paths and pop out an warning?
Thanks again,
-Ruben
*** Observed Result ***
$ make-3.82/make order_1
X=E @ prerequisite
X=E @ export_x
X=P @ private_x
X=G @ order_1
$ make-3.82/make order_2
X=G @ prerequisite
X=P @ private_x
X=E @ export_x
X=G @ order_2
*** Makefile ***
.PHONY: all export_x private_x prerequisite
global := G
export := E
private := P
X:=$(global)
order_1: export_x private_x
@echo X=$(X) @ order_1
order_2: private_x export_x
@echo X=$(X) @ order_2
export_x: export X:=$(export)
export_x: prerequisite
@echo X=$(X) @ export_x
private_x: private X:=$(private)
private_x: prerequisite
@echo X=$(X) @ private_x
prerequisite:
@echo X=$(X) @ prerequisite
-----Original Message-----
From: Paul Smith [mailto:psm...@gnu.org]
Sent: Tuesday, April 03, 2012 8:15 AM
To: Brown, Ruben
Cc: bug-make@gnu.org
Subject: Re: Possible out of order execution of pre-requisite targets in 3.82
On Mon, 2012-04-02 at 23:13 -0400, Brown, Ruben wrote:
> Is this behavior by design or an unfortunately long lived bug? If it
> is by design, what purpose does maintaining this behavior serve?
>
> ***Makefile***
> .PHONY: all A B
> all: A
> VAR := 0
> A: B
> A: VAR:= 1
> B:
> @echo VAR=$(VAR) @ B
> A:
> @echo VAR=$(VAR) @ A
>
> ***Observed Behavior***
> It appears that the dependent target B is always executed after the
> evaluation of VAR:=1, when target A is the entry point.
This is by design. See the GNU make manual definition of the target-specific
variables feature:
There is one more special feature of target-specific variables: when
you define a target-specific variable that variable value is also in
effect for all prerequisites of this target, and all their
prerequisites, etc. (unless those prerequisites override that variable
with their own target-specific variable value). So, for example, a
statement like this:
prog : CFLAGS = -g
prog : prog.o foo.o bar.o
will set `CFLAGS' to `-g' in the command script for `prog', but it will
also set `CFLAGS' to `-g' in the command scripts that create `prog.o',
`foo.o', and `bar.o', and any command scripts which create their
prerequisites.
The reason for it is seen in the example above. Another common use is
something like this:
all: <all targets>
debug: CFLAGS += -g
debug: all
Now if you run "make" or "make all", you get non-debug versions. If you run
"make debug" you get the extra -g flag added to every target.
This behavior is inherited from other versions of make, which implemented the
target-specific variable feature first.
In GNU make 3.82 you can use the "private" keyword to avoid this behavior (see
the section "Suppressing Inheritance").
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@gnu.org> Find some GNU make tips at:
http://www.gnu.org http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
