C ++のMavenのような依存関係管理？[閉まっている]

いくつかのサブプロジェクトに分割されているC ++プロジェクトがあるとします。サブプロジェクトはすべてDLLを生成し、開発者のさまざまなチームが各サブプロジェクトに取り組みます。メインプロジェクトをビルドしたい場合、すべてのサブプロジェクトを自分でビルドする必要がないようにする方法はありますか？

要するに、MavenがJavaに対して行うのと同様の方法で、依存関係の管理（つまり、バイナリファイルとヘッダーに対する）を行うものを探しています。

実際、私はこれにMavenを使用しようとしましたが、手動でかなり頻繁にパッケージを作成する必要があるため、これはかなり面倒です。Mavenは最新の変更を取得できません。また、Maven内からNAntを呼び出さなければならないので、コンパイルの実行は少しハックです（NAntの機能を使用してVisual Studioソリューションを直接ビルドします）。

これを行うためのヒントやアイデアはありますか？

最初の回答：CMakeの使用をお勧めします。これは、マルチプラットフォームのメイクファイルジェネレーターです（Visual StudioまたはEclipse CDTプロジェクトも生成します）。

http://www.cmake.org/

私はそれで本当に良い経験をしました。私がそれについて気に入っている最高のことは、一般的なプロジェクト構造を作成できることでした。そのため、スクリプトを毎回変更することなく、一般的にユニットプロジェクトなどのサブプロジェクトのルックアップを含めることができます。

彼らはまた、プロジェクトに必要な、プレインストールされたビルドライブラリを見つける方法に関する多くのモジュール（Boost、QTなど）を持っています。

更新：しばらくの間、C ++のパッケージ管理を導入するための努力がありました。注目に値するいくつかのプロジェクト：

• conan.ioは主要なビルドツールと統合します。
  • CMake
  • Visual Studio
  • Makefile
  • XCode
  • ...
• CMakeに基づくcpm（CPMはアクティブに維持されていないことに注意してください。）
• バカルー

注コメントCPMで@RAMによって尖ったうちとしては、もはや積極的に維持されていません。

依存関係管理のために、このタイプのツールを実装する新しいプロジェクト（それは新興企業です）が存在します：https : //github.com/biicode（C ++依存関係マネージャー）。あなたはあなたの依存関係を追加でき、それはうまくいくはずです

現在、プロジェクトの名前はconan.ioで、JFrogによって取得されました。

更新：プロジェクトは死んでいます...残念ながら、スタートアップはプレミアムを支払う顧客を十分に得ることができなかったようですが、サーバーは正常に動作しているようです...

UPDATE2：代替プロジェクトがあるようです：conan.io（@mucahoに感謝）

以下の高レベルのビルドシステムをお勧めします。

• Maven Nar Plugin：C / C ++プロジェクトでのMavenの使用
• Gradle cppプラグイン：簡単な方法ですが、現在主な機能とロードマップを盛り込んでいます。
• ConanはよりC ++のアプローチであり、マルチプラットフォームであり、最も一般的なC ++ビルドシステムをサポートしています。

依存関係の管理だけが必要な場合は、Ivyを試してみてください。Antとうまく統合されます（NAvy はIvyサイトからリンクされているこのブログに基づいて同じことをできると思います）。

Mavenの.NetバージョンであるByldanもあります。それがあなたにとってどれほどうまくいくかはわかりません。

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

編集：

Biicodeは廃止予定です

代替： Conan.io

最近使っていたコナンをオススメします。プロジェクト内のすべての依存ライブラリとバイナリを維持することは非常に強力です。

使用済みライブラリのNuGetパッケージを作成し、依存関係管理にNuGetを使用できます。

NuGet for C ++も参照してください。

SConsの上には多くのツールがあり、Autotoolsと同様の高レベルの機能を提供して、開発者の生活を容易にします（例：WAF、SNOCS）。残念ながら、SCons自体に大きな欠点があります。それは、大規模プロジェクトのコンパイル時間が長くなることです。

SNOCSを試すことをお勧めします簡単な依存関係管理を求め、単一のコマンド（コンパイラー、x86 / x64、デバッグ/リリース、静的/共有ライブラリー、テスト/）でコンパイルオプションを選択する方のために、（SCons逆）ます。ターゲットのインストールなど）。

SNOCSはまた、プロジェクト構成の出力を個別のファイルに保存することで、長いコンパイル時間の問題に取り組みます。これにより、その後のビルドで構成フェーズを完全にスキップして、直接ビルドフェーズに進むことができます（最後の機能は現在作成中です）。

大規模なソリューションではCMakeの構成が面倒になるため、ビルドシステムのメンテナンスには開発者の時間の大部分がかかります。幸いなことに、Martijnがすでに述べたように、「CMakeを使用して依存関係のあるプロジェクトを生成する」biicodeがあります。

SConsを試す

SConsは、オープンソースソフトウェア構築ツール、つまり次世代のビルドツールです。SConsは、autoconf / automakeと同様の統合機能とccacheなどのコンパイラキャッシュを備えた、従来のMakeユーティリティの改良されたクロスプラットフォームの代替品と考えてください。つまり、SConsは、ソフトウェアを構築するためのより簡単で信頼性が高く、より高速な方法です。

すべてのビルド依存システムの母であるmakeを使用することをお勧めします。

sconsを試してみてください、あなたは夢中になります。Makeは古く、維持するのが難しく、費用がかかります。