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