単一の(git)リポジトリに保存されている一連の関連する独立したC ++プロジェクトの編成に関するアドバイスをお願いします。プロジェクトはCMakeを使用します。
簡単な例として、2つのプロジェクトAとB、Bに依存するAを想定します。Aを開発するほとんどの人は、パッケージングシステムを介してBを取得します。したがって、Aのみをコンパイルします。ただし、開発者がAとBの両方を個別にコンパイル(およびインストール)できるようにする必要があります。
これが提案です:
└── Repo1
├── CMakeLists.txt (1)
├── A
│ ├── CMakeLists.txt (2)
│ ├── include
│ │ ├── aaa.h
│ │ ├── aaaa.h
│ │ └── CMakeLists.txt (3)
│ └── src
│ ├── aaa.cpp
│ ├── aaaa.cpp
│ └── CMakeLists.txt (4)
├── B
│ ├── CMakeLists.txt (2)
│ ├── include
│ │ ├── bbb.h
│ │ ├── bbbb.h
│ │ └── CMakeLists.txt (3)
│ └── src
│ ├── bbb.cpp
│ ├── bbbb.cpp
│ └── CMakeLists.txt (4)
└── test
├── CMakeLists.txt (5)
└── testaaaa.cpp
(1)すべてのプロジェクト(存在する場合)に共通のcmake変数を定義し、サブディレクトリを含めます。(2)プロジェクト自体とプロジェクトに必要なcmake変数を定義します。(3)インストールするヘッダーとコンパイルに必要なヘッダーを定義します。(4)ライブラリとバイナリを構成します。(5)テスト実行可能ファイルとテストケースを構成します。
私が理解しているように、各プロジェクトはXXXConfig.cmakeファイルを作成し、/ usr / local / share / cmakeにインストールする必要があります。CMakeのドキュメントを読むとき、これらのファイルを書くことは非常に複雑に思えます。
どう思いますか ?構造は理にかなっていますか?
このような一連のプロジェクトの実例がありますか?
CMakeLists.txt
プロジェクトごとに1 つのファイルに満足しています:(A/CMakeLists.txt
アプリ)にはB/CMakeLists.txt
(ライブラリ)が含まれていadd_subdirectory(...)
ます。