Subject: Re: [Boost-build] Failing dependency_test.py test.
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-07-19 00:07:24
On 07/18/2012 08:16 PM, Jurko GospodnetiÄ wrote:
> -- 1 --
> Why would replacing the
> DEPENDS <scanner>x.cpp : x.cpp ;
> relationship with
> INCLUDES <scanner>x.cpp : x.cpp ;
> Cause problems?
> I tried it, it makes sense, fixes the problem at hand and no internal
> Boost Build tests fail with that code.
It breaks header scanning for generated sources.
Consider this dependency graph (which
is what is generated by using INCLUDE)
x.o -----> <scanner>x.cpp
<scanner>x.cpp (internal node)
x.cpp (internal node)
Now consider a possible execution order:
update x.cpp (internal node)
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)
Note how we never rescanned <scanner>x.cpp.
The dependency graph that we need for this
to work is
x.o -----> <scanner>x.cpp (internal node)
x.cpp x.cpp (internal node)
> -- 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.
I tried the attached (hackish) patch and it
seemed to work okay.
> Am I missing something here or do we need to manually add a dependency
> between whomever is using <scanner>x.cpp and x.cpp? Effectively - this
> is the exact dependency added internally by having <scanner>x.cpp
> INCLUDE x.cpp.
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