---
# System prepended metadata

title: Build system selection

---

# Build system selection

In order to actually build the software of ADCS, a build system is needed.
For this, there exists a variety of systems that could be appropriate. 

There are two build systems that are for debate: CMake and meson+ninja. They are the most used 

## CMake
CMake has been used in the previous adcs-software. 
### Advantages
- cross-compilation
- independent of platform and compiler
- relatively fast
- supports different backends
- backward compatible
- allows easy external project download and incorporation


### Disadvantages
- cumbersome programming language
- everyone needs be able to generate projects using CMake


## meson and ninja
meson and ninja are being used by the software team in the student project MOVE
### Advantages
- very fast
- correct dependencies
- cross-compilation also supported

### Disadvantages
- quite new, so no too big user base just yet
- own language

## Conclusion
Both meson as well as CMake have been previously used. They are both relatively fast, which is necessary in a big project such as here. 
Meson is chosen, as it is already being used by the Software team within MOVE, and will support the expanding system.
## References
- https://julienjorge.medium.com/an-overview-of-build-systems-mostly-for-c-projects-ac9931494444
- https://stackoverflow.com/questions/19686223/what-are-the-benefits-purposes-of-cmake
- https://kubasejdak.com/19-reasons-why-cmake-is-actually-awesome
- https://mesonbuild.com/Comparisons.html
- https://cgold.readthedocs.io/en/latest/overview/cmake-can-not.html

# Approach to CMake
CMake requires a `CMakeLists.txt` to describe the dependencies within the project. There are different approaches on how to distribute them within the project.
- One `CMakeLists.txt` at top level: not recommended here as this will be a bigger project and one big CMakeLists.txt would complicate the extension of the software
- One `CMakeLists.txt` in each subdirectory: every single section can be easily turned on/off, each subdirectory has its own variable scope
- One `CMakeLists.txt` on top level, one in each subdirectory: same advantages as before but more freedom with `target_link_libraries`

Due to the size of the project, the first option was immediately discared. As the third option allows for all advantages from the second approach, including some more freedom, it was chosen as the CMake approach in the project.

## References 
- https://stackoverflow.com/questions/42744315/cmake-with-subdirectories
- https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/