Q:

How to force bjam to build but don't to run boost regression test suite?

I need to build boost regression test suite on a build machine (linux) and then run on a SUT (target machine, linux). The necessary boost libraries are already installed on the SUT as shared ones. I have properly installed gcc toolchain on the build machine. The SUT has no gcc at all.
I have built bjam on the build machine as native utility. Then I have cross-compiled some useful utility (process_jam_log and library_status) as described here: http://www.boost.org/doc/regression/library_status/doc/library_status.html
The main idea is to build (cross-compile) overall regression test suite on the build machine, then to copy to the SUT and finally to run on the latter. 
But when bjam builds some test it tries to run the test immediately on the build machine in the native environment.
Decisions from boost.org I have found (e.g. http://www.boost.org/development/running_regression_tests.html) suppose that someone wants to build and run the test suite on the machine boost libraries already installed on. It seems my case doesn't mentioned in google.
My question is how to force bjam to miss the run stage? Or how to reach my intention elsewhere?
UPD. I have got a pretty convenient script framework. The framework can build a test suite on the build machine, deploy it on the SUT (target), run it on the target, get overall useful information about that launch and finally analyse whether the test suite passes or fails.
That's why I'm searching for some decision which operates with overall test suite but not with separate tests.

A:

I have solved the problem by patching boost source.  
The main idea of the patch is to log each of the launching test command instead of running it immediately. When overall test suite is built completely we can convert those logged commands into the launching script and then just copy the suite and the script to the target machine to be run there.  
Since I have worked with boost 1.54.0 source code, my patch is for that version. I guess the adoption of the patch for another boost version would not be difficult.
diff -pruN boost_1_54_0.orig/tools/build/v2/tools/testing.jam boost_1_54_0/tools/build/v2/tools/testing.jam
--- boost_1_54_0.orig/tools/build/v2/tools/testing.jam  2013-05-21 08:14:18.000000000 +0400
+++ boost_1_54_0/tools/build/v2/tools/testing.jam   2015-07-23 19:24:42.000000000 +0300
@@ -492,23 +492,8 @@ if --verbose-test in [ modules.peek : AR
 actions capture-output bind INPUT_FILES output-file
 {
     $(PATH_SETUP)
+    echo $(LAUNCHER) "$(>)" $(ARGS) "$(INPUT_FILES)" >> "$(>).runtest"
-    $(LAUNCHER) "$(>)" $(ARGS) "$(INPUT_FILES)" > "$(output-file)" 2>&1
-    $(.SET_STATUS)
-    $(.RUN_OUTPUT_NL) >> "$(output-file)"
-    echo EXIT STATUS: $(.STATUS) >> "$(output-file)"
-    if $(.STATUS_0)
-        $(.CP) "$(output-file)" "$(<)"
-    $(.ENDIF)
-    $(.SHELL_SET)verbose=$(.VERBOSE_TEST)
-    if $(.STATUS_NOT_0)
-        $(.SHELL_SET)verbose=1
-    $(.ENDIF)
-    if $(.VERBOSE)
-        echo ====== BEGIN OUTPUT ======
-        $(.CATENATE) "$(output-file)"
-        echo ====== END OUTPUT ======
-    $(.ENDIF)
-    exit $(.STATUS)
+    exit 0
 }

