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

Subject: [Boost-commit] svn:boost r79581 - trunk/tools/build/v2/build
From: jurko.gospodnetic_at_[hidden]
Date: 2012-07-18 09:24:40

Author: jurko
Date: 2012-07-18 09:24:40 EDT (Wed, 18 Jul 2012)
New Revision: 79581
URL: http://svn.boost.org/trac/boost/changeset/79581

Log:
Updated Boost Build implementation note comment related to why it adds an INCLUDES relation between all sources registered for a single Boost Build action.
Text files modified: 
   trunk/tools/build/v2/build/virtual-target.jam |    16 ++++++++++++++--                        
   trunk/tools/build/v2/build/virtual_target.py  |    26 ++++++++++++++++++--------              
   2 files changed, 32 insertions(+), 10 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 09:24:40 EDT (Wed, 18 Jul 2012)
@@ -761,14 +761,26 @@
             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) ;

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 09:24:40 EDT (Wed, 18 Jul 2012)
@@ -797,14 +797,24 @@
 
         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)