bug-make
[Top][All Lists]
Advanced

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

Re: target-specific 'define'd variables (3.80)?


From: Boris Kolpackov
Subject: Re: target-specific 'define'd variables (3.80)?
Date: Wed, 7 Jul 2004 10:34:16 -0500
User-agent: Mutt/1.5.6i

Paul D. Smith <address@hidden> 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

Attachment: signature.asc
Description: Digital signature


reply via email to

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