From 714ed09cf41c59d4fac3a5404ea01968645ca815 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jurko=20Gospodneti=C4=87?= Date: Wed, 18 Jul 2012 13:24:40 +0000 Subject: [PATCH] Updated Boost Build implementation note comment related to why it adds an INCLUDES relation between all sources registered for a single Boost Build action. [SVN r79581] --- src/build/virtual-target.jam | 16 ++++++++++++++-- src/build/virtual_target.py | 26 ++++++++++++++++++-------- 2 files changed, 32 insertions(+), 10 deletions(-) diff --git a/src/build/virtual-target.jam b/src/build/virtual-target.jam index 282359e1f..b5ca94488 100644 --- a/src/build/virtual-target.jam +++ b/src/build/virtual-target.jam @@ -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) ; diff --git a/src/build/virtual_target.py b/src/build/virtual_target.py index 9d3c52cb4..b0e1ffbb4 100644 --- a/src/build/virtual_target.py +++ b/src/build/virtual_target.py @@ -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)