Paul D. Smith <[EMAIL PROTECTED]> writes: > It's not really clear to me when it's that useful to query, at a > _GLOBAL_ scope like this, what target-specific variables are set for a > given target.
This will allow (theoretically) hierarchical namespaces, e.g., .PHONY: /a% /a/b% /a%: foo := FOO /a/b%: bar := BAR $(warning $(/a/b:foo)) # prints FOO $(warning $(/a/b/c:bar)) # prints BAR This would be somewhat equivalent to namespace a { foo := FOO namespace b { bar := BAR } } > Remember that these queries will be evaluated at makefile > read-in time, not runtime, so much of the information is potentially not > even available yet. > > Not only that, but make can't even _know_ what the full set of > target-specific variables are for a given target until that target is > actually ready to be invoked... the scope of target-specific variables > could depend on the target->prerequisite path make used to get to this > target and decide to build it. Right. That brings us to this question: what is target-specific variable inheritance useful for? Any non-academic examples? I, for instance, am using it to propagate -fPIC flag to object compilation: %.o: %.c gcc $(pic_flag) -o $@ -c $< %.so: pic_flag := -fPIC libfoo.so: foo.o bar.o There are two big problems with this approach: * If I say `make foo.o' the object will be compiled without -fPIC and if later I say just `make' the shared library will be broken. * It doesn't scale to the case when I want to build both shared library and archive: libfoo.a: foo.o bar.o all: libfoo.so libfoo.a IMO, the target-specific variable inheritance feature is in conflict with make's assumption that the way object file is built does not depend on which target-prerequisite path triggered it; when make needs the same prerequisite for some other target it will just reuse it without re-building it or checking whether it was built with the same resulting set of target-specific variable values. What do you think? -boris
signature.asc
Description: Digital signature
_______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make