[RFC, WIP] Cmake build infra

[antoinealb]

This is the current status of my work on the CMake integration. It is not really ready to be used, but I wanted to get feedback as early as possible. For now only the UWB beacon is working, and I am expecting to fix the others pretty soon.

I encourage everyone to try it, and see if you like the CMake workflow.

@SyrianSpock, I think you are the most experienced with CMake, so I would be happy to have a review from you on the cmake infra itself.

Summary of the changes:

1. The includes for modules now live in a include directory for each library. For example the includes for the PID filters live under lib/pid/include/pid. This avoids having accidental dependencies: it is not impossible to include a header from a non-linked library.
2. Each module has its own test executable, and all the executables are built together. Before each platform had its own set of tests, and they all went in the same exec. It is now easier to have other tests, such as integration tests or tests from third party libraries running.

Things missing (probably not exhaustive):

• CAN bootloader integration
• UAVCAN messages are sometimes recompiled, sometimes not. Still working on it.
• Only UWB firmware builds
• For now it is not possible to build a board with and without the bootloader. Is it something that we really need ? In practice I feel that we are always using the same config (without bootloader for master, with bootloader for motor).
• Continuous integration, which is now botched up..
• Testing on robot

Advantages of using cmake:

• It is possible to use CMAKE_EXPORT_COMPILE_COMMANDS to generate Clang's compile command database. This in turn can be used for smart autocompletes, linters, etc.
• Faster build, especially incremental build (havent measured the progress, but feels faster).
• We now own 100% of the build system and do not rely on ChibiOS for it.
• Ability to generate IDE projects (Eclipse, Xcode) for those who would like it.
• No more packager that can be forgotten to run.

[antoinealb]

Friendly ping @SyrianSpock 👼

[SyrianSpock]

Do we plan to merge soon?

[msplr]

Nice, It builds! Does it run on hardware?

[antoinealb]

Nice, It builds! Does it run on hardware?

It does ! At least tested for the uwb-beacon. Bootloader integration is not yet ported over though.

[SyrianSpock]

So, what's the plan? Are we merging this?

[antoinealb]

Well CI is failing, and only one board is ported to the new build system, so I guess the answer is "not yet".

Current status:

• I am working on porting master-firmware
• I believe @nuft is working on can-io-firmware
• CAN bootloader integration is not complete yet, but should not be too hard to do.

[SyrianSpock]

Ok, so the project is still alive :+1:

[antoinealb]

Yes, it got rebased this weekend, and many commits are still in my home laptop.

[msplr]

I started with can-io in a branch (sould probably wok on this branch though). There I added bootloader config support (without touching the bootloader repo). I’m struggling with version.c generation and linker issues with some missing syscalls.

[antoinealb]

I can probably write version.c generation. I also had some issues with linker and syscalls but i don't remember how I fixed those. Fortunately, I will have to do it again for master-firmware.

[antoinealb]

@nuft I included version.c generation on this branch. Please push to another branch as I will often force push here.

[antoinealb]

@nuft you might want to link lib/chibios-syscall/newlib_syscalls.c in your build, helped a lot for me.

[msplr]

@antoinealb is it possible that you forgot to commit cmake/master.cmake? Or where do you define MCU, board name, compiler flags, etc for master-firmware?

[antoinealb]

@antoinealb is it possible that you forgot to commit cmake/master.cmake? Or where do you define MCU, board name, compiler flags, etc for master-firmware?

Yes its likely. You can use uwb-beacon.cmake as reference.

[msplr]

you might want to link lib/chibios-syscall/newlib_syscalls.c in your build, helped a lot for me.

yes, it helped. CAN-IO builds now but flash section is overflown. Need to investigate why the binary size blew up.

[msplr]

I managed to reduce the size, however I'm still 20k behind the previous build size.

I also observed that the chibios-syscalls library does not overwrite the default implementation (for example operator delete(), which ends up calling the newlib implementation.) This could have something to do with the library order during linking but I'm not sure. My temporary workaround was to build the sources directly without using the library archive.

[antoinealb]

Can you try playing with visibility settings ? https://stackoverflow.com/questions/17080869/what-is-the-cmake-equivalent-to-gcc-fvisibility-hidden-when-controlling-the-e

I also built the sources directly for chibios-syscalls, which sucks. Maybe we can use an INTERFACE library for that, will need to dig down in it.

[SyrianSpock]

Are we close to a mergeable state? I worry that soon, the code will change a lot and make you redo this PR work

[msplr]

Already part of #273