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