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
> The symptom of this problem is that you run "bjam", it does something
> successfully. You then run it again, and it does something more.
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.
Maybe I'll fix this later.
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk