8

いくつかの構成 (Linux および Windows ビルド、共有/静的リンク、機能の有無など) をサポートするプロジェクトに取り組んでいるとします。これらすべての構成をビルドするには、さまざまなバージョンのサード パーティ コンポーネントが必要です (gcc または msvc、共有/静的、指定されたプリプロセッサ定義などでビルド)。したがって、最終的には、プロジェクトだけでなく、プロジェクトが使用しているすべてのライブラリについて、これらすべての構成を管理するという問題が発生します。

単一プロジェクトの複数の異なる構成の管理を容易にする一般的なソリューション/アプローチ/ソフトウェアはありますか?

基準:

  • セットアップの容易さ、つまり、プロジェクトを最初から構築するのにどれくらいの時間を費やす必要があるか?
  • 管理の容易さ。つまり、新しい依存関係を追加したり、既存のものを削除したりするのは難しいですか?
  • エラープルーフ、つまり、開発者が依存関係を変更してビルドを中断する頻度はどれくらいですか?

これまで、いくつかのアプローチを試してきました。

  1. VCS の下にすべての構成のビルド済みパッケージを保存します。

    長所: プロジェクトが小規模な場合のセットアップの容易さ (作業コピーを更新すれば準備完了)。管理の容易さ (必要な構成ごとに 1 回ライブラリーをビルドします)。エラー防止 (VCS クライアントは作業コピーの変更について通知します)。

    短所: 分散型 VCS (GIT、Mercurial など) ではうまく機能しません。リポジトリは急速に拡大し、最終的に単純な「クローン」操作は耐えられなくなります。また、実際には必要のない多くのもの (つまり、Linux で作業している場合は Windows ライブラリ) をダウンロードすることになります。また、ライブラリを実装している場合、ライブラリのユーザーは、プロジェクトに統合することでこれらすべての問題を継承します。

  2. ビルド済みパッケージの代わりにライブラリ ソースを保存します。

    長所:セットアップが簡単。

    短所: 新しいライブラリを追加するのは非常に面倒です。構成ごとにビルド スクリプトとソース パッチを提供する必要があります。しかし、それは氷山の一角にすぎません。あなたの依存関係には独自の依存関係があり、独自の依存関係などがあります...最終的にGentooディストリビューションのようなものになる可能性は十分にあります:)

  3. 外部サーバーのどこかに、ビルド済みのパッケージを含むアーカイブまたはフォルダーのみを保存します。

    長所:問題を解決します...一種の。

    短所: セットアップが簡単ではありません (手動でアーカイブをコピーする必要があります)。管理はそれほど簡単ではありません (各ライブラリを手動でサーバーに追加する必要があります)。変更履歴はありません。サーバーに何かを置いたり、有用なものを削除したりするのを忘れやすいため、エラー防止ではありません。

    少し改善されたアプローチ: 集中化された VCS (SVN など) を使用して、すべてのサードパーティ ライブラリを保存できます。これにより、作業がより簡単になります。ただし、単純なファイル ストレージとして使用する場合は、変更履歴を一元化することはできません。また、サブリポジトリとして使用する場合は、多くの不要なライブラリを含む巨大なリポジトリが得られます。

4

1 に答える 1

2

このようなタイプの問題に直面した場合は、構成管理ツールを学習して使用を開始する必要があります(選択したSCMの通常の技術に加えて)。CMはプロセスであり、構成管理ツールの一部を使用することはこのプロセスの一部です。

現在、さまざまなCMツールを豊富に取り揃えており、最適なツールまたは好みのツールを選択できます。私の視点から、シェフは「みんなにとって最良の選択」です、あなたのマイレージは変わるかもしれません

于 2012-12-03T14:53:04.853 に答える