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
> 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
> that you've worked around... not being able to read the target spcific
> attributes from "VAR on TARGET = X" assignments. Reading those values
> 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:
> 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
> 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
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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk