I would like some advises on the organization of a set of related but independent C++ projects stored in a single (git) repository. The projects use CMake.
For a simplified example we imagine 2 projects A and B, A depending on B. Most people developing A will get B via the packaging system. Thus they will compile only A. However, we should allow developers to compile both A and B themselves (and install it), separately or together.
Here is a proposal :
└── 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 - Define the common cmake variables for all projects (if any) and includes the subdirectories.
- Defines the project itself and the project's required cmake variables.
- Defines the headers to install and the ones required for compilation.
- Configures the library and binaries.
- Configures the test executables and test-cases.
As I understand it, each project should produce a XXXConfig.cmake file and install it in /usr/local/share/cmake. Writing these files seem quite complicated when reading the documentation of CMake.
What do you think ? Does the structure make sense ?
Do you happen to have a working example of such a set of projects ?
CMakeLists.txtfile per project:A/CMakeLists.txt(the app) includesB/CMakeLists.txt(the library) usingadd_subdirectory(...).