Boost logo

Boost-Build :

Subject: Re: [Boost-build] Failing test.
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-07-16 19:50:41

On 07/15/2012 10:00 PM, Jurko Gospodnetić wrote:
> Hi.
>>> On 07/15/2012 03:19 PM, Jurko Gospodnetić wrote:
>>>> If you or someone else could take a look - I'd be grateful... I hope
>>>> to have the time to look into it again tomorrow or a bit later during
>>>> the week...
>>> The problem is a result of these dependencies:
>>> INCLUDES x.cpp : ;
>>> DEPENDS <object(c-scanner)>x.cpp : x.cpp ;
>> A workaround is remove the DEPENDS and
>> use SEARCH instead of LOCATE for <object(c-scanner)>x.cpp.
>> This works because I already dealt with
>> this problem for generated sources found
>> by SEARCH. Actually, now that I think about
>> it, using SEARCH is probably better, anyway,
>> because b2 enters any target with LOCATE in
>> the explicit_bindings table.
> Thanks for taking the time to look into this. However, my mind is
> blown... :-)
> I'll have to learn about stuff in Boost Build/Jam I never before dealt
> with to get my head wrapped around this. At the moment I do not know:
> - where these dependencies are set

It's in virtual-target.actualize

> - what the internal nodes are actually for

The internal node is used to store
the sibling dependencies created

> - what <object(c-scanner)>x.cpp stands for

It's the target for x.cpp with a scanner.
I left out part of the grists in the
actual target name.

> - what <object(c-scanner)>x.cpp stands -> x.cpp stands for

I means, <object(c-scanner)>x.cpp depends on x.cpp.

> - what <object(c-scanner)>x.cpp stands -> x.cpp (internal node) stands
> for
> - how SEARCH & LOCATE variables come into all of this since I thought
> the problem was not in how the targets were getting bound but in the
> fact that Boost Jam is comparing x.cpp & timestamps when they
> should be completely unrelated...

The problem is that Boost.Build is creating
two targets for the same file. <p...>x.cpp
is the actual target that is created by the
action. <p...-object(c-scanner)@...>x.cpp
refers to the same file, but has a scanner
attached. virtual-target.jam currently
models this with DEPENDS, which doesn't
quite have the right behavior. If we use
SEARCH for <p...-object(c-scanner)@...>x.cpp,
Boost.Jam knows to bind it to the existing
target, and we can leave out DEPENDS.

In Christ,
Steven Watanabe

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at