Single CMakeLists.txt for both Release and Debug

[jlonnberg]

Describe The Problem To Be Solved A csolution is currently translated into seperate cmakelists.txt for Debug and Release flavours. It would be beneficial to align these and run with "Ninja Multi-Config" for cmake instead, to have one single cmakelists.txt describing all available configurations.

[brondani]

Fundamentally csolution build-types allow the selection of different components and/or source files while CMake configurations are stricter and would typically differentiate only concerning compile options. In practice this flexibility in csolution requires a context to be translated in CMake targets rather than CMake configurations. For example csolution can enable the EventRecorder component for debugging purposes and disable it for release targets.

@jlonnberg Can you please explain what are the benefits of having Debug/Release flavours at configuration level instead of target level?

[jlonnberg]

@brondani A file can easily be placed as configuration specific using cmake-generator expression. It feels wrong not to utilize the strengths of CMake which really is build management, i.e., handle configurations with different files and options.

I envision that a csolution should be translatable into a single CMake structure with all included projects and configurations. As I stated in the .cprj discussion, this would automatically solve interdependencies. As of now, I guess that the user needs to specify their projects in a specific order for them to build properly of project-1 depends on project-2 in the csolution file.

Moreover, this makes the csolution concepts compatible with any IDE using cmake's file API's out of the box as well. I'd be more than happy to discuss this further!

[brondani]

@jlonnberg Thanks for the answer.

Moreover, this makes the csolution concepts compatible with any IDE using cmake's file API's out of the box as well

Would you like to talk more about it?

Feel free to join our weekly meetings: https://linaro.atlassian.net/wiki/spaces/CMSIS/overview https://linaro-org.zoom.us/j/98302382714?pwd=SVdtS0ZGWlg1cXVBRU9JUkpNa21CUT09

[brondani]

I did an experiment by opening the attached multi-config.zip project in 2 popular IDEs but didn’t work out of the box:

CLion 2023.2.2 By default it only brings a "Debug" profile. Any other configuration needs to be added manually. Different build directories are created for each profile, it seems the Ninja Multi-Config is not fully exploited.

VS Code extension CMake Tools 1.15.31 From the command palette it’s possible to "Select Variant" but only one of the default configurations can be selected (Debug, Release, RelWithDebInfo or MinSizeRel) so it is not possible to trigger custom builds via IDE buttons, unless the custom configurations are manually added to settings.json.

Another problem with this approach is that the compilation database (compile_commands.json) is common for all targets and configurations – the database alone may not suffice for a language server to find the right entries resulting in wrong intellisense info.

On the other hand, when the contexts are described as separated CMake targets, all of them are correctly listed in the project outline and can be individually selected and built in both IDEs.