Overview

The elcap build command compiles your Trident IoT project inside an isolated container using the Trident IoT SDK build toolchain. The container is pulled or built automatically — you do not need to install any compilers or SDKs on your host machine.

You can run:

elcap build --help

to view usage help at any time.

Command Usage

elcap build

Build the current project.

Options

--option	description	default
--target	Build target chip (e.g. T32CZ20B)	project.target from trident.toml
--debug	Enable debug build	True
--release	Enable release build	False
--jobs	Maximum number of parallel build jobs	Number of CPU cores minus 1
--clean	Delete all build artifacts before building	False
--args	Additional arguments appended to the cmake --preset command	None
--engine / -e	Container engine to use (podman or docker)	Auto-detected
--build-image / -b	Force rebuilding the container image instead of downloading it	False
--wsl-optimized / --no-wsl-optimized	Enable WSL filesystem optimization (Windows only)	--wsl-optimized
--help	Print help for this sub-command

CMake Presets

Trident IoT projects use CMake presets to define how a project is configured and built for each supported chip target. ElCap drives this process by running two commands inside the build container in sequence:

cmake --preset <target>

cmake --build --preset <target> --parallel <jobs>

The <target> value is derived from your project's target field in trident.toml and the build mode flag you pass to elcap build. For example, building a T32CZ20B project in debug mode uses the preset named T32CZ20B.Debug:

cmake --preset T32CZ20B.Debug

cmake --build --preset T32CZ20B.Debug --parallel 7

The available presets and what they configure (compiler flags, linker scripts, output directories, etc.) are defined in the CMakePresets.json file that ships as part of your project's generated source tree. ElCap does not modify that file — it simply selects the right preset based on the target and build mode you specify.

If a build/ directory already exists for the selected target, the configure step (cmake --preset) is skipped and only the build step is run. Delete the build directory with elcap clean to force a full reconfigure.

Modifying the CMake Commands

Some projects require passing extra arguments to CMake that are not captured in the preset — for example, to enable a custom toolchain file, set a CMake cache variable, or activate a verbose build. ElCap provides two ways to do this.

Using --args (one-off, per invocation)

The --args option appends a string of arguments to the cmake --preset command for a single build invocation. This is useful for temporary overrides during development or debugging.

elcap build --args "-DCMAKE_VERBOSE_MAKEFILE=ON"

The resulting configure command becomes:

cmake --preset T32CZ20B.Debug -DCMAKE_VERBOSE_MAKEFILE=ON

--args only affects the configure step. It has no effect on cmake --build.

Using trident.toml (persistent, per project)

For arguments that should always be applied whenever the project is built, you can declare them in your trident.toml file under the [build] section. This keeps the configuration in version control alongside your project and avoids requiring every developer to remember to pass extra flags manually.

[project]
name = "my_project"
category = "z-wave"
target = "Linux-LR2021"
template = "z-wave/radio_cli"
 
[sdk]
version = "v2026.06.00-ga"
 
[build]
config_args = ["--toolchain toolchain.cmake"]
build_args = ["--verbose"]

config_args — a list of arguments appended to the cmake --preset command
build_args — a list of arguments appended to the cmake --build command

Both fields are optional. If neither is present, the [build] section can be omitted entirely.

When both config_args and --args are in use, config_args is applied first and the --args value is appended after:

cmake --preset Linux-LR2021.Debug --toolchain toolchain.cmake <value of --args>

ElCap Documentation