Re: [jamboost] SEARCH_FOR_TARGET

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-15 10:34:05

David Abrahams wrote:

> >> 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....
>
> For each target s named in $(srcs), it returns the path that will be
> used as the target's binding.

I believe this can be done simpler

for local s in $(srcs)
{
paths = [ on $(s) return $(LOCATE) $(SEARCH) ] ;
source-file += $(paths[1]) ;
}

Actually, the code you use would return the "target", not path. 

I really have to document the rule.

> > Please note also that SEARCH_FOR_TARGET works only during
> > scanning/binding stage... it won't be usefull before.
>
> Well, it does seem to work as intended where I've used it.

Because where you use it, it works just like GLOB... 

The point of SEARCH_FOR_TARGET is somewhat different.
Say you have target <src/foo>a.h with LOCATE of "src/foo/bin".
Say during scanning you've created target name <src/foo/a.cpp#scanner>a.h
and that "src/foo/bin" is in include path.
Then SEARCH_FOR_TARGET will be able to find that <src/foo/a.cpp#scanner>a.h
is actually the same as <src/foo>a.h, so that you'll INCLUDE <src/foo>a.h and
get dependency on the generated header, not on some unrelated target which
accidentaly has the same binding (as Jam assumes).

> > Or you suggest putting "SEARCH" there, implicitly?
>
> Actually, I was suggesting putting LOCATE followed by SEARCH there,
> implicitly.

Did semantic description above change your mind?

- Volodya