From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-15 09:51:18
David Abrahams wrote:
> >> I was wondering if we really need this builtin, since we have Glob and
> > True.
> >> we can find out about SEARCH and LOCATE on any target.
> > I thought about it before implementing the rule. The problem is that
> > you'll have, for each included target,
> > 1. take next directory in SEARCH
> > 2. see if there's target of the same name placed there
> > 3. otherwise, see if there's file of the required name
> > for each direcotry in SEARCH. And (3) is exactly how common handling of
> > "SEARCH" works. I'd rather reuse and augment existing core functionality
> > than redoing everything in Jam code.
> OK, but notice what I had to do in the latest testing.jam to replace
> the effect of binding every source target.
> for local s in $(srcs)
> source-files += [
> SEARCH_FOR_TARGET $(s:G=)
> : [ on $(s) get-var-value LOCATE SEARCH ]
> ] ;
Sorry, I don't understand what this code is supposed to do....
Please note also that SEARCH_FOR_TARGET works only during
scanning/binding stage... it won't be usefull before.
> This would have been a bit easier if the rule acted in a way that
> corresponded more-closely to what the rest of bjam is doing. For one
> thing, I had to explicitly eliminate the grist on the target. For
> another thing, I had to explicitly supply LOCATE and SEARCH.
As I've said, it works during scanning only, where this is not a problem.
> Also, there's already a function in the core which does almost exactly
> what SEARCH_FOR_TARGET is doing (it looks very much like a copy/paste
> job). That's a bit too much code duplication for my level of comfort.
Unfortunately, I found it very hard to avoid that duplication.
> Would a function which accepted gristed target names and an optional
> sequence of paths to search in would fit more seamlessly into the
Don't know. What "optional sequence of paths" means? It already accepts a
sequence of paths? Or you suggest putting "SEARCH" there, implicitly?
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