CMake based build for the firmware

[sarath-menon]

Hi guys. In case anyone is looking for a CMake based build for the firmware, I have a working version here: https://github.com/sarath-menon/crazyflie-firmware

The key advantages are:

• An easier way to organize subfolders and add modules
• An organized template for linker flags, compiler flags etc
• Cleaner working directory after building

[knmcguire]

Ah nice! Thanks for sharing. If you would compare it to the Kconfig build we are using now, what are the difference between that? And how about building the app layer examples?

@whoenig you are a fan of cmake as well :) perhaps you have some questions too?

[sarath-menon]

Thanks for your reply

1. I'm currently using the autoconf.h generated by the default kconfig configuration. As a next step, I'm thinking of using a zephyr-like system for kconfig - A python gui generates the autoconf.h file, and CMake conditionally includes the C/C++ depending on the configuration. The user experience would be the same as the current kconfig build

2. The app layer examples don't work now, but that can be easily fixed with a couple of extra CMake files.

3. Additional functions in log.h to support logging from C++ files. This allows for modules and other core files to be written in C++. Eg. C++ counterparts have been added for the system.c and stabilizer.c files (system.cpp and stabilizer.cpp)

[whoenig]

I wouldn't say I am a fan - I am using it as it is the de-facto standard for C++ projects these days. It's better than plain make in the sense that it can track dependencies automatically. Given that we just "recently" had the switch to kconfig, I am not sure how excited I am about another build system change (this always makes maintaining forks pretty hard).

Another thing to consider are the Python bindings (should be pretty easy to support in cmake as well).

[knmcguire]

haha oke yeah I guess I could have reworded it as an heavy cmake user actually 😉 but yes, we are not planning to switch to cmake soon just yet. For us internally switching to kconfig took a lot of time and the same will hold for switching to cmake, so we don't have the capacity to do it anytime soon. This can perhaps pose as an example if we'd like to do it in the future (maybe if we want to go full ROS 2 or something but I see us first moving to Rust first which uses a different build system)

But it is quite a nice usecase anyway :)