3

私は bjam で構築しているかなり単純な Boost.Python 拡張機能を持っています。問題は、物事が起こる順序が意味をなさないことであり、それを修正する方法がわかりません。

私のプロジェクトは、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 ファイルを実行する効果があります。このファイルは、'import hello_world_ext' を実行して、拡張機能が正しくビルドされたことをテストし、その後、いくつかの簡単な単体テストを実行します。それらがすべて成功すると、bjam は成功を報告します。

問題は、bjam が'convenient_copy' ルールを実行する前に Python テストを実行することがあるようです。これは、拡張機能の以前のバージョンでテストを実行し、新しいバージョンで上書きすることを意味します。これは、頻繁に bjam を 2 回実行しなければならないことを意味します。実際、2 回目の bjam は、実際に何かを実行するため、何かが古くなっていることを認識します。3 回目以降は、さらにソースを変更するまで何もしません。これは、依存関係が正しくない場合の古典的な double-make 問題のようなものです。

これに関する主な問題は、成功したビルドが失敗することが多く (既存の拡張機能が悪かったため)、悪いビルドが成功したと表示されることです。実際、この行動に気付くのに数週間かかりました。おそらく偶然ではなく、気が狂ってしまうと思ったのとほぼ同時に...

また、これは OS X よりも Linux で頻繁に行われるようですが、完全にはわかりません。私は両方の環境にかなり均等に時間を割いています。

また、bjam の「jamfile」構文が非常にわかりにくいと感じるのは私だけでしょうか? 私が単に理解していない、または適切なドキュメントを見つけることができない、ボンネットの下で多くのことが起こっています。代わりにmakeまたはSConsを喜んで使用しますが、あちこちで壊れた例が原因で、それらを機能させることができませんでした。私を本当に混乱させているのは、私のファイルに取り掛かる前に、bjam がどのように多くの他のターゲットを構築するかということです。私は GNU Make と SCons に精通しているので、bjam を放棄して代わりにそれらのいずれかを使用する価値はありますか?

4

1 に答える 1

2

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 を使用する場合は、ユーザー マニュアルを必ずお読みください。私の個人的な経験では、それを最初から最後まで読んだ後、他のビルド システムよりも Boost.Build を選択しています。YMMV

于 2012-10-02T10:35:24.350 に答える