The project uses static libraries for the modules. The reassoning behind this is that the main purpose of this refactoring is to modularize the code base. Static linking does not change how the app is compiled or installed. This keeps things simple for now. But for future improvements modules can be linked dynamically to allow of updating individual modules without recompilation if the ABI does not change.

Directory structure

The current directory structure looks like this.

refactoring
├── app
│   ├── CMakeLists.txt
│   └── src
│       └── main.cpp
├── CMakeLists.txt
├── modules
│   ├── ModuleA
│   │   ├── CMakeLists.txt
│   │   ├── include
│   │   │   └── moduleA
│   │   │       └── ClassA.h
│   │   └── src
│   │       └── ClassA.cpp
│   ├── ModuleB
│   │   ├── CMakeLists.txt
│   │   ├── include
│   │   │   └── moduleB
│   │   │       └── ClassB.h
│   │   └── src
│   │       └── ClassB.cpp
│   └── ModuleC
│       ├── CMakeLists.txt
│       ├── include
│       │   └── moduleC
│       │       └── ClassC.h
│       └── src
│           └── ClassC.cpp
└── README.md

16 directories, 13 files

This is mostly straightforward - app and modules are separated. Each module has its own directory in which CMakeLists.txt specifies how to should be built.

Structure of module include directory

Only maybe unexpected thing is that every module include directory contains another directory e.g. ModuleA/include/moduleA/ClassA.h. This is to prevent conflicts when including files with same name from different modules. It also allows be visible from which module the included file in the app is from.

app source file:

// app/main.cpp
`#include "moduleA/ClassA.h"`

If there are many modules a programmer of the app does not get lost where did the class come from. This makes it easy to locate the file without the need for searching. In the module itself it most inner directory is included so that we don't need to specify the module.

module source file:

// ModuleA/src/ClassA.cpp
#include "ClassA.h"