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

Subject: Re: [Boost-build] Failing dependency_test.py test.
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2012-07-22 09:44:18

[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?

   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.

>> -- 2 --
>>    I tried removing that DEPENDS relationship declaration all-together
>> and replacing it with (code from virtual-target.actualize()):
>>
>>    SEARCH on $(name) = [ path ] ;
>>
>>    However - this does not not cause any <scanner>x.cpp --> x.cpp
>> dependency to be added and so the action for building x.o gets run
>> without x.cpp being generated first.
>>
>
> This won't work correctly for NOTFILE targets.

   Yup, that and it failed to work fo file targets because I did not 
notice that the LOCATE binding method was still being used in 
file-target.actualize-location() - effectively overriding my SEARCH binding.

> I tried the attached (hackish) patch and it
> seemed to work okay.

   Thanks for the patch. That pointed me in the right direction. I 
committed a test for the whole problem and a fix based on your patch
(minus one internal optimization you most likely made locally and 
included in the patch by mistake, plus some additional commenting).

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

   Best regards,
     Jurko Gospodnetić