[Boost-commit] svn:boost r79583 - trunk/tools/build/v2/build

Subject: [Boost-commit] svn:boost r79583 - trunk/tools/build/v2/build
From: jurko.gospodnetic_at_[hidden]
Date: 2012-07-18 10:08:35

Author: jurko
Date: 2012-07-18 10:08:35 EDT (Wed, 18 Jul 2012)
New Revision: 79583
URL: http://svn.boost.org/trac/boost/changeset/79583

Log:
Boost Build no longer needs to add a fake INCLUDES relationship between targets generated by a single Boost Build action (reapplying revision [79571]). This is already done by Boost Jam internally for a single Boost Jam action and in case when the Boost Build action is actually a rule registering multiple actions - this was not causing any desirable behaviour.
Text files modified: 
   trunk/tools/build/v2/build/virtual-target.jam |    25 -------------------------               
   trunk/tools/build/v2/build/virtual_target.py  |    21 ---------------------                   
   2 files changed, 0 insertions(+), 46 deletions(-)

Modified: trunk/tools/build/v2/build/virtual-target.jam
==============================================================================
--- trunk/tools/build/v2/build/virtual-target.jam	(original)
+++ trunk/tools/build/v2/build/virtual-target.jam	2012-07-18 10:08:35 EDT (Wed, 18 Jul 2012)
@@ -761,31 +761,6 @@
             DEPENDS $(actual-targets) : $(self.actual-sources)
                 $(self.dependency-only-sources) ;
 
-            # 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) ;
-            }
-
             # Action name can include additional rule arguments, which should
             # not be passed to 'set-target-variables'.
             toolset.set-target-variables

Modified: trunk/tools/build/v2/build/virtual_target.py
==============================================================================
--- trunk/tools/build/v2/build/virtual_target.py	(original)
+++ trunk/tools/build/v2/build/virtual_target.py	2012-07-18 10:08:35 EDT (Wed, 18 Jul 2012)
@@ -797,27 +797,6 @@
 
         self.engine_.add_dependency (actual_targets, self.actual_sources_ + self.dependency_only_sources_)
 
-        # 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 no
-        # 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)
-
         # FIXME: check the comment below. Was self.action_name_ [1]
         # Action name can include additional rule arguments, which should not
         # be passed to 'set-target-variables'.