make - Support: sr #103149, namespaces for included files
You are not allowed to post comments on this tracker with your current authentication level.
sr #103149: namespaces for included files
Submitter: | None | ||
Submitted: | Wed 23 Jun 2004 01:53:58 PM UTC | ||
Votes: | 1 | ||
Category: | None | Priority: | 5 - Normal |
Severity: | 2 - Minor | Status: | None |
Privacy: | Public | Assigned to: | None |
Originator Email: | -email is unavailable- | Open/Closed: | Open |
Operating System: | None |
Tue 12 Sep 2006 11:05:42 AM UTC, comment #4: |
Ian <ian_jd> |
Wed 08 Feb 2006 05:26:44 PM UTC, comment #3: Something like this would require very careful thought, and the rules for evaluation would be complex. Suppose we had something like:
|
Paul D. Smith <psmith>![]() |
Tue 21 Sep 2004 02:57:35 AM UTC, comment #2: The solution in the comment (using .SCOPE, .ENDSCOPE) does not appear to actually work. It gives an error " * missing separator. Stop." using make 3.80 or the CVS make. |
Anonymous |
Wed 21 Jul 2004 02:50:44 AM UTC, comment #1: .ALIAS TOPLEVEL_CFLAGS=CFLAGS # keep a reference to this
|
Anonymous |
Wed 23 Jun 2004 01:53:58 PM UTC, original submission:
Just an idea for the future:
|
Anonymous |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There is 1 vote so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2013-06-19 | nachumk | Carbon-Copy | - | ![]() |
Added nachumk |
Thank you for the reply. I hadn't noticed it until now.
To answer the points you raised (or at least clarify my meaning):
Localizing all variables automatically would be nice, but I think that it is probably too far from the "way make works" to be imlpemented easily. And actually I was not so concerned about this as such. My main purpose was to stop trampling on the global BIZ and "peer" BIZ declarations. Given that, I think it would be acceptable for the evaluation to print "global". It would be nice to have a way to "localize" any reference of course, but I am pretty much ok with deferred evaluation remaining the way it is. So to expand your example:
BIZ = global
scope FOO {
BIZ = local
BAR = $(BIZ)
}
scope BAZ {
BIZ = local
BAR = ${localreference $(BIZ)}
}
scope BAM
{
BIZ := local
BAR := ${BIZ}
}
all: @echo foobar = ${FOO::BAR}, bazbar = ${BAZ::BAR}, bambar = ${BAM::BAR}
would echo the following
foobar = global, bazbar = local, bambar = local
Though obviously the notation for localizing a variable reference sould be nicer. Verbosity is just for illustration purposes while this feature doesn't exist :) I think the FOO::BIZ you use is not really ok, since the person then has to know the name (and probably degree of nestedness) of the current local scope.
I must admit that mostly I was thinking of them as .PHONY targets, but I think that basically the "real target" would be the scopeless target name.
i.e.
scope FOO {
afile: echo "foo::afile" > $@
.PHONY: prepare_afile
prepare_afile: afile
}
afile: echo "afile" > $@
echo "afile" > afile
echo "foo::afile" > afile
echo "foo::afile" > afile
Basically this allows someone to componentize the make more easily, as in the "a.mk, b.mk, c.mk" example in the original savannah request item. (well, more easily, ignoring the existance of recursive make)
That's not to say it would not be also nice to have some optional way to manipulate the scoped targets to e.g. prepend a directory without rewriting every rule, but that is building a house on imaginary foundations, so I'll stop there.