2つのライブラリと2つのテストプログラムをビルドしているうちに、一見単純な問題を偶然見つけました。スタティックライブラリとSConsの一時的な依存関係
問題：2つの静的ライブラリlibAとlibBがあり、libBはlibAに依存しています。私はlibBを使用するすべてのプログラムを明示的にlibAにリンクさせたくありません。プログラムがライブラリBにリンクすると、ライブラリAにリンクする必要があることをSConsに見てほしいです。
この問題を説明する簡単な例を作成しました。
svn checkout https://example-repository.googlecode.com/svn/trunk example-repository
か、tarボールhereをダウンロードすることができます：私は、適切なファイルのホスティングを見つけることができませんでしたし、これは、関連するプログラミングされているので、私は小さなSVNリポジトリを作成しました。
SConsには、推移的なライブラリの依存関係を表現するためのサポートが組み込まれていませんが、若い従兄弟のWafはこれをサポートしています。 Wafブックの「使用」機能については、documentationを参照してください。 Boost build systemにもこの機能があります。under a different name Pythonを少しコード化したい場合は、SConsでこれを実装することもできます。
コールバックを構成変数（つまり、Python関数呼び出しを通じて拡張される文字列）として定義する機能があります。その関数呼び出しは、構文解析時に（つまり、SConscriptsにあるメソッド呼び出しを通して）計算した何らかの依存グラフに基づいて必要なライブラリの推移的なリストを計算し、すべてのターゲットに対してライブラリの完全なリストを繰り返す必要はありませんまたは環境。
libBとlibAとは何ですか？それらは1つの大きな.oであるlibsか、複数の.oファイルで構成されていますか？
libが複数の.oファイルで、libAの.oファイルの1つを使用するlibBの.oファイルの1つで関数を呼び出すと、libBの.oと依存するlibA .oが取得されます。 libAから何かに依存しないlibB .oの関数を使用している場合、バイナリにはlibB .oファイルしかありません。
コマンドがあればこのように、：
cc -o a.out a.c libA.a libB.a
をあなただけlibBとLIBAの両方から必要な部品を取得します。
tarballの例（投稿の終わりのリンクを参照）のように、単純なオブジェクトファイルを含んでいます。 – hochl
+1興味深いリンク！私はwafのマニュアルをチェックアウトしますが、私が見ていることから、これは良い選択肢かもしれません。一方、私は既にSConsでいくつかのカスタムビルダーを実装し始めました... – hochl
私の現在のソリューションは、ビルド間の依存関係を得るための他の方法は見つけていないので、依存関係情報を含む追加の構成ファイルに基づいて依存グラフを作成します動的にターゲットを絞る。 – hochl