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-22 10:39:19

AMDG

On 07/22/2012 06:44 AM, Jurko Gospodnetić wrote:
> [This is a bit updated repost of a message I sent 3 days ago but that
> somehow does not seem to have gotten through (can not find it on gmane).]
> 
>   Hi.
> 
>> It breaks header scanning for generated sources.
>>
>> Here's why:
>>
>> Consider this dependency graph (which
>> is what is generated by using INCLUDE)
>>
>>    x.o -----> <scanner>x.cpp
>>     |
>>     |
>>     v
>> <scanner>x.cpp (internal node)
>>     |     \
>>     |      \
>>     v       \
>>    x.cpp     v
>>           x.cpp (internal node)
>>
>> Now consider a possible execution order:
>> update <scanner>x.cpp
>> update x.cpp (internal node)
>> update x.cpp
>>    execute actions for x.cpp
>>    rescan x.cpp creating x.cpp (internal node 2)
>> update x.cpp (internal node 2)
>> update <scanner>x.cpp (internal node)
>> update x.o
>>
>> Note how we never rescanned <scanner>x.cpp.
> 
>   Ok, I have been researching this 'rescanning' done by Boost Jam, but
> can't really seem to grasp why we would want to rescan the
> <scanner>x.cpp target in this case. :-s
> 
>   Isn't that target bound to the same file as x.cpp and anything
> dependent on <scanner>x.cpp is already dependent on <scanner>x.cpp
> (internal) and through it on x.cpp? Wouldn't 'rescanning' <scanner>x.cpp
> then never find any new dependencies?
> 

Suppose that x.cpp has #include <a.h>.
x.cpp /does not exist/ yet, when make0
is run, so this dependency isn't found
in the initial header scan.  Rescanning
x.cpp doesn't find this dependency because
x.cpp doesn't have the scanner installed.
To find it we have to rescan <scanner>x.cpp
after x.cpp is updated.

>   I'd really like to add a test detecting this problem if possible but
> still seem to be missing something in understanding all of this. :-( It
> kind of freaks me out that neither any internal Boost Build tests or a
> complete Boost library build catch this.
> 

It's a fairly rare condition where this
actually matters.  Anything that depends
on x.cpp already needs to be updated, so
the only effect of the dependency is to
control the update order.  Thus, the problem
only manifests if x.cpp #includes a
generated header.

>   I assume the term 'hackish' relates to how the scanner targets are
> recognized in file-target.actualize-location(). I think this needs to be
> cleaned up by reorganizing who exactly in that class hierarchy knows
> about scanners (e.g. can non-file or searched-lib targets be scanned?)
> and added a FIXME note to this effect...
> 

Yep.

In Christ,
Steven Watanabe