RE: Possible out of order execution of pre-requisite targets in 3.82

[Brown, Ruben]

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:address@hidden 
Sent: Tuesday, April 03, 2012 8:15 AM
To: Brown, Ruben
Cc: address@hidden
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 <address@hidden>          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