Boost 的 bjam 在构建完成之前正在运行测试

Question

我有一个相当简单的 Boost.Python 扩展，我正在用 bjam 构建它。问题是事情发生的顺序对我来说没有意义，我不知道如何解决它。

我的项目包含一个带有 Jamroot 的根目录和一个带有 Jamfile、C++ 文件、头文件和 Python 脚本的项目子目录。

在根目录中，我有一个看起来像这样的 Jamroot 文件，主要是从示例和文档中拼凑而成。它与项目的 Jamfile 是分开的，因为我实际上想在将存在于其他子目录中的几个项目之间共享它。

import python ;

if ! [ python.configured ]
{
    ECHO "notice: no Python configured in user-config.jam" ;
    ECHO "notice: will use default configuration" ;
    using python ;
}

use-project boost
  : ./boost ;

project
  : requirements <library>/boost/python//boost_python ;

# A little "rule" (function) to clean up the syntax of declaring tests
# of these extension modules.
rule run-test ( test-name : sources + )
{
    import testing ;
    testing.make-test run-pyd : $(sources) : : $(test-name) ;
}

build-project hello_world ;
# build-project [[other projects]]... ;

然后我有一个包含我的“hello_world”项目的子目录(名称已更改以保护无辜者)，其中包含一个 Jamfile:

PROJECT_NAME = hello_world ;

import python ;

python-extension interpolation_ext :
  $(PROJECT_NAME).cpp
:
  <define>FOO
;

# Put the extension and Boost.Python DLL in the current directory, so that running script by hand works.
install convenient_copy
  : $(PROJECT_NAME)_ext
  : <install-dependencies>on <install-type>SHARED_LIB <install-type>PYTHON_EXTENSION
    <location>.
  ;

# Declare test targets
run-test $(PROJECT_NAME) : $(PROJECT_NAME)_ext test_$(PROJECT_NAME)_ext.py ;

'convenient_copy' 确实很方便，但不幸的是，我没有找到太多关于它的文档。

无论如何，我的想法是，当我在“hello_world”项目目录中时，我会更改代码并定期输入“bjam”。这具有构建 Python 扩展然后运行 ​​test_hello_world_ext.py 文件的效果，该文件执行“导入 hello_world_ext”以测试扩展是否已正确构建，然后是一堆相当琐碎的单元测试。如果全部通过，则 bjam 报告成功。

问题 似乎有时 bjam 在运行“convenient_copy”规则之前运行 Python 测试，这意味着它会在以前的版本上执行测试扩展名，然后用新版本覆盖它。这意味着我经常不得不运行 bjam 两次。事实上，bjam 第二次知道某些东西已经过时了，因为它确实做了一些事情。第三次和随后的时间它什么都不做，直到我进一步更改源代码。当依赖项不正确时，这就像经典的双重制作问题。

这样做的主要问题是，它经常无法成功构建(因为现有的扩展很糟糕)，而其他时候它会显示错误的构建是成功的。实际上，我花了几个星期才注意到这种行为，大约在同一时间，我觉得自己快要疯了，也许这并非巧合……

它似乎在 Linux 上比在 OS X 上更频繁地执行此操作，但我不完全确定。虽然感觉是这样，但我将我的时间平均分配在两种环境之间。

此外，我是唯一一个发现 bjam 的“jamfile”语法完全令人困惑的人吗？幕后发生了很多我根本不理解的事情，或者可以找到足够的文档。我很乐意改用 make 或 SCons，但由于到处都是损坏的示例，我无法让它们正常工作。真正让我感到困惑的是 bjam 如何在进入我的文件之前构建许多其他目标，我认为这会使编写 makefile 变得非常棘手？由于我对 GNU Make 和 SCons 非常熟悉，是否值得我花时间放弃 bjam 而改用其中之一？

Answer 1

在 jamfile 中声明目标的顺序并不决定构建目标的顺序。使用依赖项来控制构建顺序。它会在这里完成:

更改 run-test 规则以接受需求参数:

rule run-test ( test-name : sources + : requirements * )
{
    import testing ;
    testing.make-test run-pyd : $(sources) : $(requirements) : $(test-name) ;
}

修改 $(PROJECT_NAME) 目标声明以添加对 convenient_copy 的依赖要求:

run-test $(PROJECT_NAME) : $(PROJECT_NAME)_ext test_$(PROJECT_NAME)_ext.py : <dependency>convenient_copy ;

关于jamfile语法等部分:

如果你用 Boost.Build 做任何事情，除了非常琐碎的事情，你绝对应该阅读它的 User Manual .我个人的经验是，在从头到尾阅读它之后，我每天都会选择 Boost.Build 而不是其他构建系统。 YMMV