boost/build
2
0
Fork 0
mirror of https://github.com/boostorg/build.git synced 2026-02-14 00:32:11 +00:00
Code Issues Projects Releases Wiki Activity

Updated Boost Build implementation note comment related to why it adds an INCLUDES relation between all sources registered for a single Boost Build action.

Browse Source 
[SVN r79581]
This commit is contained in:
Jurko Gospodnetić
2012-07-18 13:24:40 +00:00
parent 1b98bbbf74
commit 714ed09cf4
2 changed files with 32 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
src/build/virtual-target.jam
View File

@@ -761,14 +761,26 @@ class action
DEPENDS $(actual-targets) : $(self.actual-sources)
$(self.dependency-only-sources) ;
# This works around a bug with -j and actions that produce multiple
# target, where:
# This used to work around a bug with -j and actions that produce
# multiple targets, where:
# - dependency on the first output is found, and the action is
# started
# - dependency on the second output is found, and bjam noticed that
# command is already running
# - instead of waiting for the command, dependents of the second
# targets are immediately updated.
# Current Boost Jam implementation already works around the problem
# the same way internally. The only difference being that it does
# so only when an actual Boost Jam action is encountered while we
# do this even if our Boost Build action actually modeling a rule
# that will then register one or more Boost Jam actions. In that
# case our INCLUDES relation added here will affect the build
# behaviour but it will not be solving any actual problem. The only
# thing it might seem like it is doing is forcing multiple separate
# actions to be run all together or none at all but it will not do
# that completely either - it would miss the case when one of the
# action targets depends on a target that needs to be updated and
# another does not.
if $(actual-targets[2])
{
INCLUDES $(actual-targets) : $(actual-targets) ;

26
src/build/virtual_target.py
View File

@@ -797,14 +797,24 @@ class Action:
self.engine_.add_dependency (actual_targets, self.actual_sources_ + self.dependency_only_sources_)
# This works around a bug with -j and actions that
# produce multiple target, where:
# - dependency on the first output is found, and
# the action is started
# - dependency on the second output is found, and
# bjam noticed that command is already running
# - instead of waiting for the command, dependents
# of the second targets are immediately updated.
# This used to work around a bug with -j and actions that produce
# multiple targets, where:
# - dependency on the first output is found, and the action is started
# - dependency on the second output is found, and bjam noticed that
# command is already running
# - instead of waiting for the command, dependents of the second
# targets are immediately updated.
# Current Boost Jam implementation already works around the problem the
# same way internally. The only difference being that it does so only
# when an actual Boost Jam action is encountered while we do this even
# if our Boost Build action is actually modeling a rule that will then
# register one or more Boost Jam actions. In that case our INCLUDES
# relation added here will affect the build behaviour but it will not be
# solving any actual problem. The only thing it might seem like it is
# doing is forcing multiple separate actions to be run all together or
# none at all but it will not do that completely either - it would miss
# the case when one of the action targets depends on a target that needs
# to be updated and another does not.
if len(actual_targets) > 1:
bjam.call("INCLUDES", actual_targets, actual_targets)