Re: [jamboost] Wrapping up new design

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-03 13:02:25

----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>

> OK, looking at some deatil last night I fail to see how it would not
require a
> core extension.
>
> The basic problem I ran into is that there is now way, that I can see, of
> figuring out that one has crawled up past the top of the filesystem.
>
> Am I missing something?

Perhaps not. You could do something like this:

SEARCH on project-config.jam = . .. ../.. ../../.. ../../../..
../../../../.. ... ;
modules.load project-config ;

But I agree that you'd need to pick a maximum depth-of-search.

> 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.

> 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!
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.

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.