Customizing CMLs to produce multiple executables

[SamMiddleton]

I have a project that builds two different programs with conditional compilation.
(I'll call the project Foo and the programs FooA and FooB)

I currently have a #define in main.h that I comment/uncomment manually to toggle between them, but I'd like to hoist that into the build system.

I could probably manage it with presets, but it looks like I'd have to manually define FooADebug, FooARelease, FooBDebug & FooBRelease, which would be tedious.
(If someone does know of a way to make orthogonal sets of presets, I'd be interested)

A more promising approach would seem to be something along the lines of:

project(Foo)
add_executable(FooA)
add_executable(FooB)
target_compile_definitions(FooB PRIVATE FOO_B)

I can see how I would do this if I was writing all the CMakeLists.txt's myself, however while the top CML says

#
# This file is generated only once,
# and is not re-generated if converter is called multiple times.
#
# User is free to modify the file as much as necessary
#

 cmake/stm32cubemx/CMakeLists.txt contains no such comment (and seems to contain content that would be regenerated) and assumes that the project contains one executable named ${CMAKE_PROJECT_NAME} (which gets set in the top-level CML)

Is there a way to do what I want that won't be broken if I regenerate the code?

[Nawres GHARBI]

Hi @SamMiddleton 

you can use an STM32H7 Dual core project as example 

declare your projects like in the mx-generated.cmake file and control build with these commands

option(BUILD_FooA "Build FooA target" ON)

option(BUILD_FooB "Build FooB target" ON)

I think a dual core project will be a best example that could help you whit this kind of project

[SamMiddleton · Accepted solution]

Hi.

I generated an empty dual core H7 project to look at (after stumbling over the fact that not all H7's are dual core), and I get the feeling that it's an overpowered approach that would leave lots of redundancy for my very similar apps.

I'm leaning towards just using presets, especially as I have found the inherits field.

I noticed that e.g. CM7/mx-generated.cmake is very similar to cmake/stm32cubemx/CMakeLists.txt and contains a "do not edit" comment, supporting my hypothesis that the latter isn't safe to edit.

I think it would be neat if the function calls in such files that modify the properties of the ${CMAKE_PROJECT_NAME} target were bundled into a function or macro (perhaps called target_stm32cubemx_setup) taking a target name that got called in the editable CML.