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.txt
file per project:A/CMakeLists.txt
(the app) includesB/CMakeLists.txt
(the library) usingadd_subdirectory(...)
.