複数のサブプロジェクトに分割されているC++プロジェクトがあるとします。サブプロジェクトはすべてDLLを生成し、開発者の異なるチームが各サブプロジェクトで作業します。メインプロジェクトをビルドする場合、すべてのサブプロジェクトをビルドする必要を回避する方法があります私自身?
要するに、MavenがJavaで行うのと同様の方法で、依存関係管理(つまり、バイナリファイルとヘッダー)を行うものを探しています。
実際、これにはMavenを使用しようとしましたが、パッケージを手動で非常に頻繁に作成する必要があるため、これはかなり面倒です。Mavenは最新の変更を取得できません。また、Maven内からNAntを呼び出す必要があるため、コンパイルの実行はちょっとしたハックです(NAntの機能を使用してVisual Studioソリューションを直接構築します)。
これを行う方法のヒントやアイデアはありますか?
最初の回答:CMakeの使用をお勧めします。これは、マルチプラットフォームのメイクファイルジェネレーターです(Visual StudioまたはEclipse CDTプロジェクトも生成します)。
本当にいい経験をしました。私が一番気に入っているのは、一般的なプロジェクト構造を作成できることです。そのため、スクリプトを毎回変更することなく、単体テストなどのサブプロジェクト検索を一般的に含めることができます。
また、プロジェクトに必要なプリインストールされたビルドライブラリの検索方法に関する多くのモジュールもあります(Boost、QTなど)。
Update:その間、C++のパッケージ管理を導入する努力がありました。見る価値のあるプロジェクト:
注コメントcpmの@RAMで指摘されているように、アクティブに維持されなくなりました。
依存関係管理のために、このタイプのツールを実装している新しいプロジェクト(スタートアップ企業)が存在します: https://www.biicode.com/ (C++依存関係マネージャー)。依存関係を追加できれば機能するはずです。
現在、プロジェクトの名前は conan.io です。これらは JFrog によって取得されました。
UPDATE:プロジェクトは dead ...残念なことに、スタートアップは十分な有料の顧客を獲得できなかったようだが、サーバーは正常に動作しているようです...
UPDATE2:代替プロジェクトがあるようです: conan.io (thanks @mucaho)
次の高レベルのビルドシステムをお勧めします。
MakeとGCCは、本当に良い依存関係チェックのための素晴らしいコンボです。
GCCは、たとえば、特定のヘッダーに依存するすべてのソースファイルを再構築できるように、「make」依存ファイルを自動的に生成できます(-MDコマンドラインスイッチ)。
メイクファイルにカットアンドペーストする簡単なルールがいくつかあります。
# compile c files
%.o: %.c
${CC} ${CFLAGS} -c $< -MD -MF $(<:%.c=%.dep) -o $@
# compile c++ files
%.opp: %.cpp
${CPP} ${CPPFLAGS} -c $< -MD -MF $(<:%.cpp=%.dep) -o $@
オブジェクトファイルがOBJ_CおよびOBJ_CPPリストで宣言されている場合:
.PHONY: cleandep
cleandep:
rm -f $(OBJ_C:%.o=%.dep) $(OBJ_CPP:%.opp=%.dep)
-include $(OBJ_C:%.o=%.dep) $(OBJ_CPP:%.opp=%.dep)
もちろん、makeは他のプロジェクトなどとの依存関係を追跡できます。必要に応じて共有ライブラリも再構築します。
たとえば、他のチームが常に共有フォルダーに最新のDLLを配置する場合:
myapp: ${SRC_CPP} ${LIB_DIR}other_team.lib
...
${LIB_DIR}other_team.lib: /shared_folder/latest/other_team.lib
cp /shared_folder/latest/other_team.lib ${LIB_DIR}other_team.lib
conan をお勧めします。これは最近使用していました。プロジェクト内のすべての依存ライブラリとバイナリを維持することは非常に強力です。
使用済みライブラリ用のNuGetパッケージを作成し、依存関係管理にNuGetを使用できます。
NuGet for C++ も参照してください
SConsの上には多くのツールがあり、開発者の作業を楽にするAutotoolsの機能に似た高レベルの機能を提供しています(例:WAF、SNOCS)。残念ながら、SCons自体には大きな欠点があります-大規模プロジェクトのコンパイル時間が長くなります。
[〜#〜] snocs [〜#〜] (SConsは逆になっています)簡単な依存関係管理を探し、単一のコマンドでコンパイルオプションを選択する場合は(コンパイラ、x86/x64、デバッグ/リリース、静的/共有ライブラリ、テスト/インストールターゲットなど)。
SNOCSは、プロジェクト構成出力を個別のファイルに保存することにより、長いコンパイル時間の問題に対処しようとします。
CMakeの構成は、より大きなソリューションでは退屈になります。そのため、ビルドシステムのメンテナンスには、開発者の時間の大部分がかかります。幸いなことに、Martijnがすでに言及したように、 biicode があります。これは、「CMakeを使用して依存関係を持つプロジェクトを生成します」。