CおよびC ++用のパッケージ管理システムがないのはなぜですか？[閉まっている]

パッケージ管理システムが存在するプログラミング言語がいくつかあります。

• TeXのCTAN
• PerlのCPAN
• Python用のPip＆Eggs
• Maven for Java
• ハスケルのカバル
• Rubyの宝石
• NodeJSのnpm
• フロントエンドJavascriptおよびCSSのバウアー
• C＃のnuget
• PHPの作曲家

そのようなシステムには他の言語がありますか？CとC ++はどうですか？（それが主な質問です！）なぜそのようなシステムがないのですか？yum、apt-getまたはその他の一般的なパッケージ管理システム用のパッケージの作成は改善されていませんか？

実際、（顕著なブースト名声の）一部の人々は、Rypplと呼ばれるそのようなシステムを作成して確立するために一生懸命働いています。このようなSystem for C ++を確立するのは困難です。なぜなら、それを指示できる単一のプレーヤーがないからです。-更新：残念ながら、放棄されています。

2番目の質問では、通常のパッケージマネージャー（クロスプラットフォームではない）は、開発者の特定のニーズを処理しません。

Cの問題、さらにC ++の問題は、それらがより異種言語であることだと思います。これらの言語は標準化されていますが、異なるオプションまたはサポートされる機能の異なるセットを持つ異なるコンパイラが存在します。たとえば、スタックオーバーフローでのC ++に関する質問をGCC / Linuxで完全に動作する例で投稿したことを覚えています。誰かが私のコードは非標準であるという回答をすぐに投稿しました。

質問で言及されているようなパッケージシステムを持つことは、すべての一般的なオペレーティングシステム上のすべての主要なコンパイラーによって均一にサポートされる共通の言語とライブラリを持っていることを意味します。たとえば、C ++パッケージをダウンロードして、別のオペレーティングシステムのコンパイラYで開発されたため、コンパイラXのバージョンでコンパイルされないことを発見する必要はありません。

makeおよびconfigureスクリプト（Linux、cygwin、およびその他のUnixフレーバーで一般的に見られる）に基づくシステムが機能すると想像できました。しかし、なぜVisual Studioユーザーはそれを採用する必要があるのでしょうか？Microsoftコンパイラー（およびライブラリー）に基づいたパッケージシステムを起動した場合も同様です。

C ++が急速に進化している言語であり、その標準がすべてのコンパイラーによって完全にサポートされるまで常に時間がかかるという事実は、問題を軽減しません。

あなたの質問に答えるために私たちが尋ねる必要がある質問は、「他の言語/エコシステムは、独自の集中化されたパッケージリポジトリを持っていることから何を得るのだろうか？」および「これはC / C ++に適用されますか？」

最初の質問に対する答えは、新しい言語の最初のプロモーションに関係していると感じています。早期採用者は、初心者がエコシステムに参入し、有用でテスト済みのコードを取得し、独自に貢献することを可能な限り簡単にしたいと考えています。明らかな理由から、「使用状況グラフ」には常に単一のルート（言語の作成者）があります。通常、（少なくとも最初は）1つの参照実装があるため、共有したいコードはそれに準拠する必要があります。

これにより、ダウンロードしてコンパイルするだけのパッケージを簡単に作成できます。確かに、CまたはC ++が2013年に導入された場合、コミュニティは同様の進化パスをたどることができましたが、そうではなく、パッケージマネージャーを適用する単一の一般的なツールチェーンはありませんでした。これにより、このようなプログラムの実装は面倒になりすぎて面倒になりません。（ユーザーにlibfoo-gccとlibfoo-vsのどちらを選択させるべきですか？解決するのはパッケージャーに任せますか？それともビルドプロセス？もしそうなら、パッケージはストレートアップtarballとはどう違うのですか？）

したがって、最初の質問に対する私の答えをまとめると、パッケージマネージャーを作成するパターンは、主に採用を促進するのに役立つと思います。

そのことを念頭に置いて、このニーズを満たす単一のシステムがない理由を理解するのはかなり簡単だと思います-ニーズはCおよびC ++プログラマには存在しないからです。CおよびC ++コミュニティ（または実際にプログラマコミュニティ）にとって問題となるのは、元々暗示されていた必要性です：配布し、最新の状態に保ち、コードを貢献することです。これは、さまざまな成功度の異なる人々によって何度も解決されており、実際、1つのシステムが大きな市場シェアを獲得しています：git（およびそれ以前の他のシステム）。

基本的に問題が異なる場合、ソリューションも異なって見えますが、入力gem installと入力の違いgit cloneは無意味です。

この質問には少し混乱があります。上記のソフトウェアは、特定のプログラミング言語の拡張機能を管理します。これらは、選択したプログラミング言語でプログラムで使用できるライブラリとソースコードを提供します。

一般的なシステムレベルのパッケージマネージャーは通常、アプリケーションに関係なく使用できるバイナリパッケージを提供します。彼らはシステムとユーザーをより重視しています。もちろん、Aptitude、rpm、Entropyなどのシステムレベルのパッケージ管理システムは、バイナリまたはソースコードである任意のパッケージを提供できます。だからこそ、インストールする拡張機能のほとんどをそれらの中に見つけることができます。たとえば、Gem。

あなたがYumとApt-getまたはRigo と言ったのは、その下にあるパッケージ管理システムのユーザーインターフェイスにすぎません。

プログラミング言語のリストについてもう1つ：

• ComposerおよびPear for PHP

これはクロスプラットフォームのソリューションではないことを認識していますが、ミックスに追加する必要があります。

CoAppは最近、NuGetを使用したC ++パッケージ管理のサポートを発表しました：http : //blog.nuget.org/20130426/native-support.html

現在、これはVisual Studioコンパイラでのみ動作しますが、他のプラットフォームで動作させるために多くの要求がありました。