ここで scons ビルドの例を見てきましたが、私のプロジェクトに合ったソリューションを提供することを望んでいることがわかりました。
構造は次のとおりです。
root/
Module_A/
include/
foo.h
bar.h
src/
foo.cpp
bar.cpp
Module_.../
すべてのモジュールは、すべての .h のインクルード フォルダーと cpps の src ファイルという同じ構造に従います。各モジュールは共有オブジェクトに組み込まれます。実行可能ファイルはありません。
モジュールには相互依存関係があります。たとえば、Module_A はロギング メカニズムであり、モジュール B、C、D などで使用されます。同様に、Module_B は構成ローダーであり、他のいくつかのモジュールで使用されます。Module_C は IPC モジュールで、リストされているほぼすべてのモジュールで使用されます。最後に、Module_D はコマンド センターであり、他のすべてのモジュールとリンクしています (文字通り)。
プロジェクトをビルドするために再帰的なmakeを使用している現在のセットアップを置き換えることに興味があります。そのために必要な sconstruct と SConscripts を構築しようとしていますが、scons は言うまでもなく、作成するのも非常に新しいです。
各モジュールの .cpp と .h を .so に変換し、その依存関係を make now で行われているように自動的に解決することに興味があります。
SConscript では、現在 glob を使用して *.cpps を取得し、モジュールの './include' を CPPPATH に含めています。利用した
env.SharedLibrary(CPPATH='./include', source= (list of the cpps))
ただし、これは他のモジュールに依存するため、使用されている他のモジュールの関数が「宣言されていない」と述べて、機能しません。
階層的な scons セットアップを使用して、この種の複雑な構造を構築するにはどうすればよいですか?