Re: [jamboost] Wrapping up new design

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-01-03 16:01:51

On 2002-01-03 at 01:02 PM, david.abrahams_at_[hidden] (David Abrahams) wrote:

>SEARCH on project-config.jam = . .. ../.. ../../.. ../../../..
>.../../../../.. ... ;
>modules.load project-config ;
>
>But I agree that you'd need to pick a maximum depth-of-search.

Yea, I thought about that, and picking a max depth seems to me like a silly
restriction. The way I did it on my shell script was to use $PWD and then it's
easy to tell when the filesystem runs out [$(PWD:P) == $(PWD)], but then that
is not a portable solution.

>> As a side note, I'm also seriously thinking of removing one of the
>>limitations
>> that you've worked around... not being able to read the target spcific
>> attributes from "VAR on TARGET = X" assignments. Reading those values
>>would
>> make doing this much cleaner as I could then tell what a "SEARCH on
>> somefile.jam = PATHS" found
>
>That doesn't find anything by itself. I just sets the SEARCH variable. You
>have to do something which causes binding (i.e. include somefile.jam) to
>cause anything to be searched for.

Yes, it's the "bind" done by the include. After looking at jam source for a
few hours I'm beginning to get a reasonable understanding :-)

>> without having to blindly call "include" and
>> generating a "perror" if there was nothing found.
>>
>> For this I was thinking of syntax like so:
>>"$(targetvaraible:V=hashvariable)".
>> So for SEARCH it would something like: "$(SOMEFILE:V=SEARCH)" which would
>> evaluate to either the file it found, or null if not found. For non
>> SEARCH/LOCATE it would just evaluate to the previously set value, or null
>>if
>> not set.
>
>Oh, that's clever!

Thanks, my turn to blush :-]

>keep in mind that:
>
>1. Perforce has an internal enhancement that does the job of inspecting "on
>target" variables, but differently. I think Christopher Siewald told me it's
>something like:
>
> on <target> statement ;
>
>You can ask Richard Geiger mailto:opensource_at_[hidden] if you want to
>know, and probably get the source.

I'll look into that.

>2. Getting into this territory begins to suggest that my modules feature
>ought to be integrated with the on target variable feature somehow. They
>have a similar mechanism for localizing variable values.
>
>3. Maybe the best approach for what you want to do would be to make a BIND
>builtin rule which causes binding but doesn't include anything. It would be
>best if we could detect the difference between "found in the current
>directory" and "not found". That may already be possible if you put "." at
>the end of the SEARCH path, since you'd get ./<filename> instead of just
><filename> if the file were found.

In that case, what would you prefer? I like the $(X:V=Y) approach because it's
a variation of the current method to get at variable values. But a BIND rule
more directly expresses what is actually going on.

As for detecting "found in current directory" vs. "not found", choices are to
keep the same behaviour for found of just the filename, and to use null/empty
when not found. If implemented as a BIND rule then having return a value of
BOUND/UNBOUND might also be possible, if the bind is a side-effect.

And no putting "." in the SEARCH path doesn't return "./filename", it returns
"filename". And even more entertaining... putting "./" returns ".//filename",
and "../../" returns "../..//filename", and finally putting "./." returns
"././filename" :-\

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]