5
共通のネストされたサブモジュールを使用してGitリポジトリを整理する
私はGitサブモジュールの大ファンです。バージョンとともに依存関係を追跡できるので、以前のバージョンのプロジェクトにロールバックし、対応するバージョンの依存関係を安全かつクリーンに構築できます。さらに、ライブラリの履歴は、ライブラリに依存している（およびオープンソース化されない）アプリケーションの履歴とは別個であるため、ライブラリをオープンソースプロジェクトとしてリリースする方が簡単です。 仕事中の複数のプロジェクトにワークフローを設定していますが、単一のモノリシックプロジェクトではなく、このアプローチを少し極端にするとどうなるか疑問に思っていました。サブモジュールを実際に使用すると、ワームの潜在的な可能性があることにすぐに気付きました。 一対のアプリケーション：studioおよびplayer、および依存ライブラリcore、graphおよびを想定します。network依存関係は次のとおりです。 core スタンドアロンです graphcore（サブモジュール./libs/core）に依存 network上のcoreサブモジュール（サブモジュール./libs/core） studio依存graphし、network（サブモジュールに./libs/graph及び./libs/network） player依存graphし、network（サブモジュールに./libs/graph及び./libs/network） CMakeを使用しており、これらの各プロジェクトに単体テストとすべての作品があると仮定します。各プロジェクト（studioおよびを含むplayer）は、コードメトリックス、ユニットテストなどを実行するためにスタンドアロンでコンパイルできる必要があります。 事は、再帰的git submodule fetchであり、次のディレクトリ構造を取得します： studio/ studio/libs/ (sub-module depth: 1) studio/libs/graph/ studio/libs/graph/libs/ (sub-module depth: 2) studio/libs/graph/libs/core/ studio/libs/network/ studio/libs/network/libs/ (sub-module depth: 2) studio/libs/network/libs/core/ プロジェクトでcore2回複製されていることに注意してくださいstudio。このディスクスペースの浪費とは別に、core2回ビルドするため、ビルドシステムの問題が発生しますcore。 質問 共通のネストされたサブモジュールの複数のコピーを取得せずに、バージョン付きの依存関係とスタンドアロンビルドを取得できるように、サブモジュールを整理するにはどうすればよいですか？ 可能な解決策 ライブラリの依存関係がある程度示唆されている場合（つまり、「バージョンXで動作することがわかっている」または「バージョンXのみが公式にサポートされている」方法）次のシナリオを想像できます。 ビルドシステムを用意しgraph、networkどこで見つけるかを伝えますcore（たとえば、コンパイラインクルードパスを使用して）。「standalone」と「dependency」の2つのビルドターゲットを定義します。「standalone」は「dependency」に基づき、ローカルcoreサブモジュールを指すインクルードパスを追加します。 追加の依存関係を導入studioしcoreます：on 。次に、studiobuilds core、coreサブモジュールの独自のコピーへのインクルードパスを設定し、ビルドgraphしnetworkて「依存関係」モードにします。 結果のフォルダー構造は次のようになります。 studio/ studio/libs/ (sub-module depth: 1) studio/libs/core/ studio/libs/graph/ studio/libs/graph/libs/ (empty folder, …
50
git
cmake
submodules