C ++のパッケージマネージャーを作成するための取り組みはありますか？
私のお気に入りの言語に対する私の最大の不満の1つは、1つの統合開発環境でさまざまなライブラリを連携させるために必要な労力です。私の最大の願いは、IDEなどに特定のライブラリが必要であることを伝えることができることです。これにより、ダウンロード、コンパイル（必要な場合）、インストール、インクルードパスとライブラリパスの設定が行われます。
私が欲しいのは this ですが、C++用です。 Visual Studioで動作する方がいいのですが、gccでも問題ありません。または、それが独自の別個のシステムである場合、それも問題ありません。ただし、Windowsで動作する必要があります。
この問題を解決するために、どのような有望なプロジェクトがありますか？
MinGWを使用している場合は、apt-get/aptitudeに似たパッケージマネージャーがすでにあり、必要な処理を実行します。 mingw-get
Debianのapt-get/aptitudeと同じように動作します。すでに含まれているパッケージの中には、expat、libxml2、zlib、pthreadなどがあります。
明らかに、MinGWでの作業を開始するには、MinGWのコピーが必要になります。
Gitをパッケージマネージャーと見なしましたか？私は依存関係とサブ依存関係にgitサブモジュールを使用しており、無料のgitホスティングサービスと組み合わせて、このアイデアは非常に強力です。
Gitプロジェクトに入るだけです。
git submodule add git://somehosting.com/you/package.git
git submodule init package
git submodule update package
cd package && ./configure --stuff && make && cd ..
特定の依存関係バージョンを選択するには、
cd package && git checkout v3.2 && cd .. && git add package/
git commit -am "package version 3.2 pinned" && git Push
これで、パッケージの依存関係を特定のタグに固定し、設定をプロジェクトリポジトリに保存しました。次回誰かがするとき：
git pull && git submodule update
それらのパッケージ依存関係もv3.2に固定されます。
一部のパッケージ管理システムは、署名付きパッケージも備えています。 Gitを使用すると、 GPGでタグに署名 でき、公開鍵をキーリングに追加して確認できます。
したがって、パッケージのダウンロードと依存関係のバージョンがあり、「パッケージ署名」をエミュレートできます。欠けている部分の1つは、事前に作成されたバイナリです。これは、私の意見では絶対に必要というわけではありません。もう1つの欠けている部分は、グローバルパッケージ管理です。依存関係の依存関係が更新された場合は、各gitリポジトリを手動で管理する必要があります。
答えは、パッケージング/依存関係の管理と、構築に使用する任意のツールにCondaを使用することです（私はCMakeを使用しています）。
ここでそれをチェックしてください：
Condaは、apt-get、yum、nugetなどのパッケージマネージャーに似ていますが、いくつかの重要な利点があります。
1）完全にクロスプラットフォーム（現在はLinux、Windows、OSXですが、他のプラットフォームは簡単に追加できます）
2）使用するためにrootアクセスを必要としません。実際、システムパッケージはまったく気にしません。これは、誰かがすでにスタックを構築していることを除けば、homedirでスタック全体（必要に応じてlibcまで）を構築するのと似ています。この魔法は、パッケージを再配置可能にすることで実現されます。
3）必要な数の異なる環境を並べて維持できます。アプリケーションの1つはpython 2.7.6を必要としますが、別のアプリケーションはpython 2.7.4を必要としますか？問題ありません-それらは平和に共存できます
4）さまざまなLinuxディストリビューション用に個別のビルドを維持する必要が二度とありません。適切に構築されたConda環境は、それらのいずれでも機能します。他のプラットフォーム（WindowsやOSXなど）も忘れないでください！
5）システムまたはIT部門によって決定されたバージョンのライブラリとは結婚していません。たとえば、私はRHEL5ノードでの作業を余儀なくされました。 Python冗談があります（現在10歳以上）。Condaを使用することで、その痛みを回避し、Python that誰にも影響を与えずに欲しかった。
6）環境は配布用に「インストーラー」に圧縮できます。
7）独自のライブラリ用にファイアウォールの背後に独自のプライベートリポジトリを維持できます。パブリック集中リポジトリはBinstarと呼ばれます。依存関係はどちらか（または両方）から発生する可能性があります。
多くの人が、CondaはPythonのみのシステムであると誤解していますが、実際にはCondaはネイティブパッケージ用に作成されています（言語に依存しません）。それは巨大なPython存在感を持っています。なぜなら、その本来の動機は、Pythonの他のパッケージングシステム（pip + pypi）でのひどいネイティブライブラリサポートを克服することだったからです。
Condaの現在の唯一の問題は、Binstar（中央リポジトリ）にまだすべてのパッケージがないことです。必要なライブラリが不足していることに間違いなく遭遇しますが、それは簡単に修正できます。好きなパッケージをビルドして、Binstarにプッシュできます。私はこれを何十ものネイティブライブラリに対して行わなければなりませんでした。それは非常にうまく機能します。
C++コードを開発するときに、システム依存関係マネージャーに戻ることは決してありません。
NuGet 2.5以降、 NuGetはネイティブプロジェクトをサポートします 。ただし、パッケージを手動で作成することは非常に複雑であるため、NuGet用のCoAppのPowershellツールを使用することをお勧めします（ ドキュメントはこちら ）。これらのツールを使用して、NuGetでC/C++パッケージをホストできるようになりました。
異なるC++ライブラリが非常に異なるビルドシステムを使用することが多いため、これが発生する可能性はほとんどありません。 Autoconf、scons、make、MSBuild、VCBuild、Boost Jam、CMake、NMake、QMakeがその例です。さらに、多くのCおよびC++開発者は、YaccやBisonなどのツールを使用してコードを生成します。
MavenとNuGetは、ビルドツールのバリエーションが（比較的）少ないエコシステムをサポートしているため、同じように機能します。 Mavenの場合はAnt、NuGetの場合はMSBuild。使用中の膨大な数のC++ビルドシステムで動作するように同様のシステムを構築することは、実行不可能で非現実的です（そのようなシステムに対する需要が不足しているように見える場合）。
私は クロスプラットフォームおよびクロスアーキテクチャの分散パッケージマネージャー に取り組んできました。すべてのパッケージはプロジェクトディレクトリにインストールされます（nodejsの動作と少し似ています）。仕掛品です。
Daveedのモジュール提案がありますが、C++ 0xにはなりませんでした。
ryppl 必要なことを実行しているようで、クロスプラットフォーム：
私たちの使命は、ポータブルなモジュラーC++ソフトウェアエコシステムの条件を作成することです。
すでにGitHubでスターを付けています： https://github.com/ryppl/ryppl
CoApp があり、Microsoftのサポートがあるようです。