Re: [Boost-build] Failing dependency_test.py test.

Subject: Re: [Boost-build] Failing dependency_test.py 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 : x.bar ;
>>> 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
by INCLUDES.

>   - 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 & x.bar 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