7

CMake を使用して構築された、多くのサードパーティの依存関係を持つ大規模なクロスプラットフォーム C++ プロジェクトの物理 (ディスク上) レイアウトを再編成中です。

十分に確立されたパッケージ マネージャーが存在しないプラットフォームである Windows をサポートする必要があるため、ソース ツリーに依存するサード パーティ製ライブラリを含めることをかなり前に決定しました。ただし、Linux や Mac OS X など、当社がサポートする他のプラットフォームでは、これらのサードパーティ ライブラリの多くがパッケージとして利用できるか、システムに既に存在しており、CMake で簡単に見つけることができます。

現在のプロジェクトのレイアウトは次のとおりです。

root/
    src/
        3rd-party-lib1/       (build system modified to output to build/)
        3rd-party-lib2/       (build system modified to output to build/)
        project-module1/      (our own code)
        project-module2/      (our own code)
    build/                    (CMake is invoked from here)
        3rd-party-lib1-bin/
        3rd-party-lib2-bin/

サードパーティのライブラリは微調整されているため、ビルド時にバイナリが に出力されroot/build/<lib>/ます。

このレイアウトには複数の問題があります。

  • サード パーティのライブラリは 100% オリジナルではなくなりました。これにより、それらの更新が必要以上に難しくなります。
  • src/ディレクトリには、弊社独自のコードとサード パーティのコードが混在しているため、混乱を招きます。
  • ディレクトリはsrc/非常に大きいです。サード パーティのライブラリが含まれているためsrc/、元のソース コードの実際の量に比べて非常に大きく、独自のコードのバックアップが必要以上に複雑になります (src/ディレクトリ全体をアーカイブすることはできなくなりました)。
  • プロジェクト リポジトリ (Git) は、サード パーティのライブラリ (ドキュメント、テスト データなど、ソース以外のファイルが多数含まれている可能性があります) が含まれているため、非常に大きく、更新するたびに大きくなります。残念ながら、新しいリポジトリで再起動することを決定しない限り、ここに戻る方法はありません (残念ながらコミット履歴全体が失われます)。
  • 含まれているサードパーティ ライブラリ (zlib、libpng など) の多くは、Linux または Mac OS X でプロジェクトをビルドするユーザーにはまったく必要ありませんが、Windows ユーザーにとっては大幅に簡素化されます。

別のレイアウトは次のようになります。

root/
    3rdparty/
        3rd-party-lib1/       (100% original, contains built artifacts)
        3rd-party-lib2/       (100% original, contains built artifacts)
    src/
        project-module1/      (our own code)
        project-module2/      (our own code)
    build/                    (CMake is invoked from here)

CMake ファイルを変更して、各ライブラリの適切な場所でサード パーティのヘッダー ファイルとライブラリを探す必要があります。

ネイティブのクロス プラットフォーム プロジェクトでのサード パーティ ライブラリの処理に関するベスト プラクティスは何ですか? それぞれのプラットフォームで、開発者にとって最も驚くべきビルド エクスペリエンスにつながるレイアウトはどれですか? 既存のプロジェクトからの成功したレイアウトの具体例も歓迎します。

4

1 に答える 1

7

私の経験では、ベスト プラクティスとして次のことをお勧めします。

  • サードパーティのオープンソース ライブラリを完全にそのまま使用する場合は、ダウンロードした圧縮 tarball のローカル コピーをメインの git リポジトリ内にコミットして、ネットワーク接続の問題によってソフトウェアのビルドが妨げられるのを回避します。

  • サードパーティのオープンソース ライブラリがほぼそのまま使用されているが、微調整が必​​要な場合 (これはクロス コンパイルの場合に一般的です。多くのパッケージでは、構成手順をわずかに調整する必要があります)、圧縮された tarball と「統合された diff」を保存します。 " パッチ ファイルをメインの git リポジトリ内に配置し、ExternalProject_Add の PATCH_COMMAND ステップ内でパッチを適用します。

  • サードパーティのオープンソース ライブラリが組織によって大幅に変更または拡張される場合は、別の git リポジトリを使用してアップストリーム リポジトリへのポインタを保持します (git も使用する場合が最も簡単ですが、アップストリームの svn も管理できます)。 . アップストリームのミラーリングに使用されたブランチとは別のブランチに、組織の変更をコミットします。必要に応じて、メインの git リポジトリとこれの間にサブモジュールの関係を導入できますが、DOWNLOAD_COMMAND は任意の git リポジトリから直接フェッチできるため、技術的にはそうする必要はありません。

  • メインの git リポジトリ内にもアーカイブすることで、単一のターゲット プラットフォーム用の小規模で使用頻度の低いサードパーティ独自のバイナリを扱うことは合理的です。ただし、さまざまなプラットフォームで利用できる、サイズが大きい、または頻繁に進化するサードパーティのバイナリは、独自の git リポジトリに保存し、上記のように DOWNLOAD_COMMAND を介して取得する必要があります。

于 2013-11-02T01:39:39.223 に答える