[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How could I help now?
From: |
Paul Smith |
Subject: |
Re: How could I help now? |
Date: |
Fri, 28 Sep 2007 16:19:43 -0400 |
On Fri, 2007-09-28 at 01:05 +0200, Ramón García wrote:
> What failed was a test that referenced an automatic
> variable of a rule from another rule.
I personally think that this failure is correct, in this situation. So,
that probably means that the test is wrong.
I guess we should think about it; I can see four possible behaviors for
expanding $(T::@) (or any other automatic variable):
1. Always returns the right value regardless of where/when it's
used.
2. Always returns the empty string until after all makefiles are
read in and make starts processing the rules; then always
returns the right value.
3. Returns the empty string up until target T is processed; then
returns the right value.
4. Always returns the empty string unless we're currently
processing target T (that is, $(T::@) cannot be used outside of
the recipe for T).
Of these, #1 is what is attempted today but it's not correct, since, as
I mentioned, it cannot work 100% correctly for any automatic variable
other than address@hidden So I think we cannot go with #1.
#4 is probably what I would expect, with no other influences; I've
always considered the automatic variables to be defined only within the
scope of the target currently being processed by make. However, as you
say the current implementation of OOD requires that this work, so #4 is
not going to work for us.
Either of the other two is OK with me, since both return the "right"
value in a deterministic way (IMO "the order makefiles are read" is not
deterministic enough in make, since the prerequisites list for a given
target can be changed anywhere).
If you want to go with #3, then you should check to see if we've snapped
deps or something before doing the automatic variable assignment bit of
your patch.
If you want to go with #2, then we can just remove the automatic
assignment bit of your patch.
Anyone else have an opinion on this?
--
-------------------------------------------------------------------------------
Paul D. Smith <address@hidden> Find some GNU make tips at:
http://www.gnu.org http://make.mad-scientist.us
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist