build-cmake

Build CMake Project

Applicable Scenarios

Project Profile indicates build_system: cmake。
The user wants to configure, rebuild, or confirm firmware artifacts for a CMake MCU project.
The flashing or debugging process requires a new ELF、HEX or BIN。
You need to confirm whether the environment is ready before building (cmake, generator, toolchain).

Workspace path, or an existing Project Profile。
Optional build preset, build directory, target name, generator, build type, and toolchain file.

If CMakePresets.jsonexists, prefer using the script's --list-presets to list and select presets.
Otherwise check CMakeLists.txt, the existing build directory, and the toolchain file.
If a successful build directory already exists and is consistent with the current intent, prefer reusing it.
As soon as the script starts, it automatically reads the .em_skill.json in skill_profiles.build-cmake, reusing the parameters from the last successful build as defaults (explicit parameters take precedence; no need to manually pass --resume）；--resume It is only used to assert that the cache must exist; if there is no cache, exit non-zero. When there is no cache or the user requests re-detection, the script automatically falls back to --detect、--list-presets or manual parameter exploration.
The generator is automatically detected by the script, preferring Ninja, followed by the Make tool installed on the host machine.
For debug-oriented requests, use Debugby default; otherwise use RelWithDebInfo。

First read references/usage.md, and confirm whether this time it is to execute a build, detect the environment, list presets, or only scan artifacts.
Just run the target action directly—when the script starts, it automatically reuses the source directory, build directory, preset, target, and artifact information from the last successful build in the project root .em_skill.json (explicit parameters take precedence). Only add --resume --profile default。
If there is no cache or the user requests re-detection, the script automatically falls back to --detect、--list-presets or manual parameter exploration.
If CMakePresets.json exists, use --list-presets to list presets, then use --preset <name> to build.
If there are no presets, use --source、--build-dir、--generator、--build-type、--toolchain to manually configure the build.
Read the build results and artifact scan report output by the script, focusing on the preferred artifacts (ELF > HEX > BIN) and failure classification.
After a successful build, the script automatically updates the .em_skill.json in the project root skill_profiles.build-cmake.default; synchronize the build directory, artifact path, artifact type, and generator information to Project Profile, and hand it off to downstream skills when needed.

When cmake or the required generator is missing, return environment-missing。
When configuration or build fails due to a corrupted preset, a missing toolchain file, or an invalid target name, return project-config-error。
When the build appears successful but no flashable or debuggable artifact is found, return artifact-missing。
When multiple equally reasonable presets or firmware targets exist and any choice would be unsafe, return ambiguous-context。

On Windows, unless the workspace explicitly requires a specific Visual Studio shell, prefer Ninja, avoiding dependence on a specific developer command environment.
The bundled script uses the Python standard library and subprocess to invoke cmake, so the build scheduling path itself is cross-platform.
The build directory in the output should remain an absolute path, making it convenient for downstream flashing and debugging skills to reuse directly.

Output the configure command, build command, build directory, selected generator, and preferred artifact path.
After a successful build, persist source、build_dir、preset、generator、build_type、toolchain、target and the preferred artifact to the project root directory .em_skill.json。
Use artifact_path、artifact_kind and the detected toolchain details to update Project Profile。
After success, recommend flash-openocd or debug-gdb-openocd。

When the next step is intended to flash a program to hardware, hand off the successful build result to flash-openocd。
When the next step requires symbol information or a debugging session, hand off the successful build result to debug-gdb-openocd。