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 

(1) Define the common cmake variables for all projects (if any) and includes the subdirectories. (2) Defines the project itself and the project's required cmake variables. (3) Defines the headers to install and the ones required for compilation. (4) Configures the library and binaries. (5) 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 ?

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 

1. Define the common cmake variables for all projects (if any) and includes the subdirectories.
2. Defines the project itself and the project's required cmake variables.
3. Defines the headers to install and the ones required for compilation.
4. Configures the library and binaries.
5. 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 ?