Re: [jamboost] SEARCH_FOR_TARGET

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-16 08:05:32

Vladimir Prus <ghost_at_[hidden]> writes:

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

Yuck.

Actually I take advantage of the "2 targets bound to the same
location" thing in testing.jam for expected failures:

test -> <failed>foo -> <succeeded>foo -> sources

The action for <failed>foo -> <succeeded>foo basically echoes
something into foo, but only if building <succeeded>foo failed.

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

Good idea.
Maybe I'll fix this later.

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