Как заставить bjam собирать, но не запускать набор буст-регрессионных тестов?

Question

Мне нужно собрать набор тестов регрессионного ускорения на машине сборки (linux), а затем запустить на SUT (целевой машине, linux). Необходимые библиотеки повышения уже установлены на SUT как общие. Я правильно установил gcc toolchain на сборочную машину. У SUT нет gcc вообще.

Я собрал bjam на сборочной машине как нативную утилиту. Затем я собрал несколько полезных утилит (process_jam_log и library_status), как описано здесь: http://www.boost.org/doc/regression/library_status/doc/library_status.html

Основная идея состоит в том, чтобы создать (кросс-компилировать) полный набор регрессионных тестов на компьютере сборки, затем скопировать в SUT и, наконец, запустить на последнем. Но когда bjam собирает какой-то тест, он сразу же пытается запустить тест на машине сборки в собственной среде.

Решения от boost.org, которые я обнаружил (например, http://www.boost.org/development/running_regression_tests.html), предполагают, что кто-то хочет создать и запустить набор тестов на уже установленных библиотеках надстроек машины. Кажется, мой случай не упоминается в Google.

Мой вопрос: как заставить bjam пропустить этап бега? Или как достичь моего намерения в другом месте?

UPD. У меня довольно удобный скрипт-фреймворк. Фреймворк может построить набор тестов на компьютере сборки, развернуть его на SUT (цель), запустить его на цели, получить общую полезную информацию об этом запуске и, наконец, проанализировать, прошел или нет набор тестов. Вот почему я ищу какое-то решение, которое работает с полным набором тестов, но не с отдельными тестами.

Answer 1

Я решил проблему, исправив источник повышения.

Основная идея патча состоит в том, чтобы регистрировать каждую из запускающих тестовых команд вместо немедленного запуска. Когда весь набор тестов будет полностью построен, мы можем преобразовать эти зарегистрированные команды в сценарий запуска, а затем просто скопировать набор и сценарий на целевую машину, которая будет там выполняться.

Так как я работал с исходным кодом boost 1.54.0, мой патч для этой версии. Я думаю, что принятие патча для другой версии Boost не составит труда.

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
 }

Answer 2

Для кросс-скомпилированного тестирования вам нужно использовать вспомогательный скрипт / программу для запуска скомпилированных тестовых исполняемых файлов. Вам необходимо:

1. Напишите скрипт, который принимает единственный аргумент, являющийся путем к исполняемому файлу теста. Сценарий должен будет:
   1. Скопируйте исполняемый файл на целевой компьютер с ОС.
   2. Удаленно запустите тестовую программу на целевой машине с ОС.
   3. Захватите код выхода и результата на целевой машине ОС.
   4. Распечатайте выходные данные и верните код результата на компьютере с ОС.
2. При запуске тестовых сборок укажите сценарий выполнения теста с параметром "testing.launcher=".

Свойство сборки testing.launcher описано в документации по Boost Build Testing.