[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Smith
Subject: Re: Possible out of order execution of pre-requisite targets in 3.82
Date: Tue, 03 Apr 2012 08:14:41 -0400

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]