[Top][All Lists]

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

[bug #25140] Pattern-specific variable assignment behaves differently co

From: Paul D. Smith
Subject: [bug #25140] Pattern-specific variable assignment behaves differently compared to normal variables
Date: Sun, 28 Dec 2008 07:47:57 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008121621 Ubuntu/8.04 (hardy) Firefox/3.0.5

Update of bug #25140 (project make):

              Item Group:                     Bug => Enhancement            


Follow-up Comment #1:

The reason this happens is because pattern-specific variables are treated
very differently from target-specific variables, internally.  With
target-specific variables there is an actual target and the variables are kept
and expanded with reference to that target.  Since an explicit target is
stated, even if that target is not known already we can create one to hook
these variables to when the makefile is read in.

With pattern-specific variables there is no known target at the time the
pattern variable is defined, so pattern variables are simply kept as a list of
potential variable settings.  They are not resolved when the makefile is read
in, because there's no target to "hook" them to.  They are resolved when the
target is to be built: at that time all the pattern-specific variable patterns
are matched, one at a time, to the target and if it matches the expansion
occurs.  Obviously that comes in the second phase of the build, after the
makefiles have all been read in (and, in your example, the variable $(v) has
been reset).

It's potentially conceivable that all the pattern-specific variables with the
exact same pattern could be treated as target-specific variables are, and the
variable settings for that pattern can be combined into a "group".  However,
even that would not be 100% accurate; suppose you had two patterns "%.bar" and
"foo%.bar", then with a target of "foobaz.bar" you could reasonably expect the
pattern-specific variables to be handled as if they were target-specific
variables for "foobaz.bar"... but there's really no way to do that.

This behavior is actually quite tricky to get right: combining :=, +=,
inheritance, etc.

I'll leave this open as an enhancement request.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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