4

ネストされた階層を持つ一連の共有ライブラリとして設定された (C++) プログラムがあります。つまり、libB.so は libA.so からの関数を使用するため、libA.so に対してリンクし、libC.so は libB.so と libA.so の両方からの関数およびリンクを使用します。

現在の CMake+Ninja ビルド システムでは、並列ビルドがライブラリ間で行われていないように見えることに気付きました。つまり、Ninja は通常 12 コアを使用してビルドしますが、libA から 1 つのソース ファイルに触れ、libC では複数のソース ファイルに触れた場合、ninja は libA.so がリンクされるまで、libA ソース ファイルだけをビルドするために 1 つのプロセッサのみを使用します。その時点で、12 個のプロセッサを使用して libC ソース ファイルをコンパイルします。- また、libA ソースのコンパイルでエラーが発生した場合、ninja に -k を渡しても、libC ファイルをオブジェクト ファイルにコンパイルしようとさえしません。

確かに、libC.so のリンクは、libA.so がリンクされるまで遅らせる必要がありますが、libC ソースのオブジェクト ファイルへのソース ファイルのコンパイルは、libA のリンクのために遅らせる必要はありません。

ライブラリ間の依存関係を表現するために CMake ファイルを設定する最適な方法について、私が見逃しているものはありますか? それとも、これは忍者の仕組みの克服できない制限ですか?

4

1 に答える 1

7

これは最近、CMake メーリング リストで質問されました。開発者の 1 人からの応答により、報告された動作が意図的なものであることが確認されました。

残念ながら、これは一般に CMake プロジェクトの正しいビルドを取得するために必要です。ライブラリ「foo」で add_custom_command を使用して、コンパイル中に「foo」にリンクするライブラリ「bar」に含まれるヘッダー ファイルを生成するケースをサポートしているためです。 foo に対する bar の順序依存性以外に、この依存性を表現する良い方法がありません。

状況によっては、CMake が改善されてその制約が緩和される可能性がありますが、これはまだ行われていないようです (CMake 3.6 の時点)。これについては、Kitware イシュー トラッカーにすでにオープン チケットがあります。

更新:これは CMake 3.9.0で修正されたようですが、その変更により回帰が発生し、その後3.12.0または3.11.2で修正されました。

于 2016-07-17T21:01:34.740 に答える