Re: [jamboost] SEARCH_FOR_TARGET

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-16 01:16:29

David Abrahams wrote:

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

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

Of course you are right!

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

Not in Jam. Imagine that targets t1 and t2 are bound to the same
location. You have

INCLUDES main.h : t1 ;
some-action t2 : source ;

(and main.cpp includes main.h)

I.e. t2 is *generated* targets. Jam will understand that t2 should be rebuild 
when "source" is modified. Likewise, it will rebuild main.cpp if t1 is 
modified. But, if you change source, jam won't recompile main.cpp -- by
the time it establishes dependency, the file t1 and t2 are bound to is not 
modified.

The symptom of this problem is that you run "bjam", it does something 
successfully. You then run it again, and it does something more.

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

Frankly, whenever I need to GLOB something, I run "bjam -f-" first and
experiment with it. 

- Volodya