問題タブ [boost-build]

コンテキスト -- Boost.Python の C++ ライブラリ セットを使用して、C++ コードとのインターフェイスを構築しようとしています。主なアイデアは、QA の観点から Python のように使用して C++ コード (.so ファイル) をテストすることです。

今すぐ質問します。

1. BOOST_PYTHON_MODULE ラッパー、Python からインターフェイスするすべての .cpp に本当に含める必要がありますか? test.cpp があるとします。Boost ラッパーに test_qa.cpp を記述して、プロセスで実際の開発コードが変更されないようにすることはできませんか?

2. より明確にするために Boost.org サイトを調べました。Boost.Build と Boost.Python の違いは何ですか?

単体テストの Jamfile に 2 つの異なるターゲットを設定したいと考えています。

これは私の現在のディレクトリ構造です:

これは私のテスト/ Jamfileです：

b2 test開発時に実行できるようにしたいのですが、CI を実行b2 test-xmlして Jenkins の単体テスト レポートを生成したいと考えています。この Jamfile では、現在「test」サブディレクトリにいる場合にのみ実行できますb2 test-xml。Jamroot ディレクトリから実行しようとすると、

test-xml の作り方がわからない

何か案は？

Python バインディングを記述したい C++ コードがたくさんあります。これを機能させる最も簡単な方法と思われるため、Boost.Python を使用しようとしていますが、連携していません。ビルドしようとしている拡張モジュールのコードの一部を次に示します。

Bjam は苦痛のようで、私の Pythonpath を認識しないか、libpcap とのリンクを許可しないため、CMake を使用しています。これは私のCMakeListsファイルで、すべてを正常にインポートしてビルドできます（期待どおりにlibpcap.soを出力します）：

そして、モジュールを利用しようとする私の pcap.py ファイル:

しかし、モジュールを実行しようとすると、次のエラーが発生します。

Boost.Python が Python 3 を使用しようとしており、システムのデフォルトが Python 2.7.3 であるためだと思います。user-config.jam ファイル (boost_1_55_0 ディレクトリ内) を Python 2.7 を指すように変更して、ビルドを試みました。

Boost.Python のインストール手順 [0] は、bjam でクイックスタートをビルドしようとすると失敗するようです (多くの警告)。そのため、Boost Getting Started 手順 [1] に従って Python ヘッダー バイナリをビルドしようとしました。この問題の原因は何ですか。これを修正する方法に関する推奨事項は驚くべきものであり、私はこれに何時間も費やしました.

取り組みたいオープンソース プロジェクトの一部としてブースト ライブラリを構築しようとしています。

_{ツールセットは MinGW/gcc で、%PATH% に正しくあります。}

基本的に、どういうわけか、ブーストは現在のディレクトリにboost-build.jamあるファイルを認識していません。

適切に設定したことに注意してくださいBOOST_ROOT：

私はここで私の機知に富んでいます。バックスラッシュとスラッシュのさまざまな順列を試しました。また、からのエラーメッセージb2には path が含まれていますがC:/share/boost-build、どこから来たのかわかりません。コードベース全体を完全に検索しましたが、それを指定している可能性のある構成ファイルがどこにもありません。

それで、Boost.Build が必要になるのでしょうか?

とにかく、こちらの指示に従ってBoost.Build をビルドすると、まったく同じ問題が発生します。

( ) のビルド中Boost 1.55に、次のエラーが原因でシリアライゼーション ライブラリがスキップされました:vs2013vc120

../transform_width.hpp(151): エラー C3861: 'min': 識別子が見つかりません

にアルゴリズムヘッダーを含めることでこれを解決しましたtransform_width.hpp：

std::min が 151 行目で使用されているため、これが問題であると考えました。

これは既知の問題ですか? この問題に対する別の解決策 (ブーストの変更を必要としないもの) はありますか?

threading=multiブーストを構築するときにフラグが正確に何をするのか完全にはわかりません。ドキュメントには次のように記載されています。

これはあまり具体的ではないようです。これは、たとえばブースト コンテナーへのアクセスが保護されていることを意味しますmutexes/locksか? 私のコードのパフォーマンスは重要であるため、不要なミューテックスなどを最小限に抑えたい.

詳細:

私のコードは、マルチスレッドのサードパーティ アプリケーションに読み込まれるプラグイン DLL です。Boost を DLL に静的にリンクします (プラグインは、標準の Windows DLL 以外の依存関係を持つことが許可されていないため、これを行う必要があります)。

アプリケーションはマルチスレッドですが、DLL 内のほとんどの関数は単一のスレッドからしか呼び出されないため、コンテナーへのアクセスを保護する必要はありません。複数のスレッドから呼び出すことができるコードの残りの場所は、boost::mutexand friends を使用して明示的に保護します。

私は両方threading=multiと両方でブーストを構築しようとしましthreading=singleたが、両方ともうまくいくようですが、ここで何をしているのか本当に知りたいです。

msvc を使用してブーストをビルドするように (ソース ファイルを変更せずに) 指定する方法はありますか? いくつかのconfig.jamで、またはコマンドラインでさらに良いですか? お気に入り

variant=debug/somefeature=somevalue のようなコマンド ラインを使用する提案を見つけることができましたが、それは機能しません。