build dir for different targets

[JojoS62]

Wenn the cmake-variants.yaml has entries for different targets, then CMake complains when switching from one target to another:

CMake Error at mbed-os/tools/cmake/mbed_generate_configuration.cmake:17 (message):
[cmake]   MBED_TARGET has changed since this directory was originally configured.
[cmake]   (previously was: DISCO_F769NI).  Due to CMake limitations, this build dir
[cmake]   must be deleted and recreated from scratch (or use cmake --fresh [CMake
[cmake]   3.24 or newer]).

Is it possible to use the --fresh option? The newer cmaker 3.24 is available for a long time now and I guess it can be used without problems.
Even better would be to have target related build dirs as in mbed-os CLI2. How about changing the mbed-ce to use a build dir per target?

@multiplemonomials @ladislas @jay-sridharan

[multiplemonomials]

Unfortunately, CMake does not control its own build dir. It's set by VS Code's commands, and can be controlled via cmake.buildDirectory in .vscode/settings.json. I agree that having a different build dir for each Variant would be super useful, but it looks like this would have to be set up on the VS Code side.

This page looks like it might be useful: microsoft/vscode-cmake-tools#151 . Maybe try setting cmake.buildDirectory to something like: ${variant:board}-${variant:buildType}? Does that work OK?

[JojoS62]

Yes, you’re right, the cmake-tools extension should handle it. I will try to use the env vars.

Great! That works:

The path is also used for launch.json and flashing the app. So I will add this setting to the wiki.

    "cmake.buildDirectory": "${workspaceFolder}/build/${variant:board}-${variant:buildType}",

[ladislas]

@JojoS62 in our case we have three CMake targest:

• LekaOS + spikes + functional tests to run on real hardware
• unit tests (using Google Tests) to run on host computer
• tools for vscode and plugins

the 3 are configured independently with 3 different build directories by running:

make config              # --> _build/{TARGET_BOARD} by default 'LEKA_V1_2_DEV'
make config_tools        # --> _build_cmake_tools
make config_unit_tests   # --> _build_unit_tests

we do handle the need to change the Mbed hardware target by calling

make config                              # --> _build/LEKA_V1_2_DEV
make config TARGET_BOARD=LEKA_V1_2_DEV   # --> _build/LEKA_V1_2_DEV
make config TARGET_BOARD=LEKA_DISCO      # --> _build/LEKA_DISCO

Doing so pulls all the dependencies again and allows you to compile for the hardware target you want without reconfiguring everything, you just need:

make TARGET_BOARD={TARGET NAME}
make TARGET_BOARD=LEKA_DISCO
make TARGET_BOARD=LEKA_V1_2_DEV   
make                             # equivalent to `make TARGET_BOARD=LEKA_V1_2_DEV`

The whole logic is handled here: https://github.com/leka/LekaOS/blob/develop/Makefile

This Makefile is not related to CMake (as when you generate the project using a Makefile) -- it's a dev tool for us, that could be replaced by a script or cli

[ladislas]

The other thing for us is that we do not want VSCode to handle the configuration of the real project. People not using VSCode should still be able to configure, compile and flash from the command line.

As we are using VSCode a lot, it made sense to add this make config_tools option to make the developer's life easier, but it's not the other way around.

Here are the cmake.configureSettings:

"cmake.configureSettings": {
	"TARGET_BOARD": "LEKA_V1_2_DEV",
	"OS_VERSION": "0.0.0",
	"ENABLE_LOG_DEBUG": "ON",
	"ENABLE_SYSTEM_STATS": "ON",
	"MBED_PATH": "${workspaceFolder}/extern/mbed-os",
	"CMAKE_CONFIG_DIR": "${workspaceFolder}/_build_cmake_tools/cmake_config",
	"CMAKE_BUILD_TYPE": "Debug"
},

https://github.com/leka/LekaOS/blob/develop/.vscode/settings.template.json#L81-L89

That's what I really don't like with Mbed/Keil Studio, it forces you to use tools you might not want. And makes it harder to then setup CI/CD pipelines

[JojoS62]

thanks for sharing your configuration.
Jamies tool can be used also without VSCode via commandline, then you have to supply some defines manually. Using the environment defines in the build path works fine, I think this is a good generic solution.
And Windows does not have a make tool, its something that you have to install additional. make on top of cmake on top of ninja makes it really heavy, but for your large project it is maybe a good solution.

[ladislas]

make on top of cmake I agree. Ninja is something else, it's for cmake's internal use.

what we do with the Makefile could be replaced by pure CMake I guess, but I hadn't had time to look into it for the moment

[jay-sridharan]

Just so I'm understanding this correctly, this isn't really a plug-and-play solution with VSCode, right? You need to run make config_tools on the command line to generate the right CMake settings in VSCode, and then run CMake itself to generate the build system for the actual mbed-os based project.

Even replacing a Makefile with pure CMake won't help in this situation because VSCode won't even know to run the configuration tool in the first place.

[ladislas]

make config_tools generates the build dir and sets the cmake project. then from VSCode we run CMake: configure to pull the deps, build the compilation database, etc.

Even replacing a Makefile with pure CMake won't help in this situation because VSCode won't even know to run the configuration tool in the first place.

we'll still need to run it by hand first to configure/setup the project, as with any tools. VSCode cannot guess what it needs to do.

The idea is that instead of calling make config that in turn calls cmake ..., I can create custom targets in cmake to call to do the work.