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

Subject: [Boost-commit] svn:boost r75930 - trunk/tools/build/v2/engine
From: steven_at_[hidden]
Date: 2011-12-12 19:11:10

Author: steven_watanabe
Date: 2011-12-12 19:11:10 EST (Mon, 12 Dec 2011)
New Revision: 75930
URL: http://svn.boost.org/trac/boost/changeset/75930

Log:
Remove out of date comment.
Text files modified: 
   trunk/tools/build/v2/engine/compile.c |    25 ++-----------------------               
   1 files changed, 2 insertions(+), 23 deletions(-)

Modified: trunk/tools/build/v2/engine/compile.c
==============================================================================
--- trunk/tools/build/v2/engine/compile.c	(original)
+++ trunk/tools/build/v2/engine/compile.c	2011-12-12 19:11:10 EST (Mon, 12 Dec 2011)
@@ -504,29 +504,8 @@
 #ifdef HAVE_PYTHON
     if ( rule->python_function )
     {
-        /* The below messing with modules is due to the way modules are
-         * implemented in Jam. Suppose we are in module M1 now. The global
-         * variable map actually holds 'M1' variables, and M1->variables hold
-         * global variables.
-         *
-         * If we call Python right away, Python calls back Jam and then Jam
-         * does 'module M1 { }' then Jam will try to swap the current global
-         * variables with M1->variables. The result will be that global
-         * variables map will hold global variables, and any variable settings
-         * we do will go to the global module, not M1.
-         *
-         * By restoring basic state, where the global variable map holds global
-         * variable, we make sure any future 'module M1' entry will work OK.
-         */
-
-        LIST * result;
-        module_t * m = python_module();
-
-        frame->module = m;
-
-        result = call_python_function( rule, frame );
-
-        return result;
+        frame->module = python_module();
+        return call_python_function( rule, frame );
     }
 #endif