Re: [jamboost] SEARCH_FOR_TARGET

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-15 11:09:51

Vladimir Prus <ghost_at_[hidden]> writes:

> 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]) ;
> }

No, that just adds the first directory in which to search for the file
to source-file.

Binding doesn't work that way; I want the directory in which the file
will eventually be found.

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

As I said, it actually seems to work as intended.

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

That's sort of what I wanted.

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

I basically understand everything you wrote here, except for the very
last part. It seems as though any target which "accidentaly has the
same binding", is actually the same file, and therefore should
participate the same way in the dependency analysis.

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

I guess so.

I wonder why I didn't use GLOB. I think it might've been because we
don't have clear documentation anywhere (Perforce's fault?) and I
couldn't get it to work.

-- 
David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution