Re: [jamboost] SEARCH_FOR_TARGET

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
> system?

Don't know. What "optional sequence of paths" means? It already accepts a 
sequence of paths? Or you suggest putting "SEARCH" there, implicitly?

- Volodya