Environment Management Using Lock and Configuration Files#

This guide describes how to create, reproduce, and manage Silicon Labs Tool (SLT) and SLC configurator environments by using lock and configuration files. Use these files so that local developer machines and continuous integration (CI) systems use the same software development kits (SDKs), toolchains, and Silicon Labs command-line tools.

Clean Environment Setup#

A clean environment starts with only SLT installed manually. Install and manage all other tools with SLT.

Recommended clean environment setup steps:

Install and set up SLT by following the Silicon Labs First-Time Installation and Setup guide.
Create, modify, or use the generated user.slconf file for project configuration.
Use a .slcp or .slcw file to define the project software components.

These files help recreate a reliable and predictable environment across developer machines and CI systems.

Recommended Repository Layout#

repo-root/
  pkg.slt
  pkg.lock
  user.slconf
  autogen/
    pkg.slconf
  app/
    application.slcp
  generated/
  README.mdrepo-root/
  pkg.slt
  pkg.lock
  user.slconf
  autogen/
    pkg.slconf
  app/
    application.slcp
  generated/
  README.md

Recreating Environments from Lock and Configuration Files#

To recreate an environment, the main required files are:


File	Description
`pkg.lock`	Records the exact package versions resolved and installed by SLT.
`user.slconf`	User-editable SLC/SLT configuration file. It should usually include the SLT-generated `autogen/pkg.slconf` file. For more details, see Use SLC-CLI.
`autogen/pkg.slconf`	Generated by SLT. It contains resolved package and tool paths, such as SDK paths, toolchain paths, and installed tool locations. Do not edit this file manually because SLT may overwrite it.
`.slcp`	SLC project file that describes a single SLC application or project.
`.slcw`	SLC workspace file. Use this only when the project is organized as an SLC workspace instead of a single `.slcp` application.

A typical reproducible command-line workflow is:

slt install -f pkg.lock
slc generate <project.slcp> --slt-config user.slconf -d generatedslt install -f pkg.lock
slc generate <project.slcp> --slt-config user.slconf -d generated

To build the generated project:

cmake --preset <preset-name> -S generated/cmake_gcc
cmake --build generated/cmake_gcc/buildcmake --preset <preset-name> -S generated/cmake_gcc
cmake --build generated/cmake_gcc/build

Version Conflicts#

Version conflicts can happen when globally installed tools are used instead of SLT-managed tools, or when different branches require different SDK or tool versions.

Recommended handling:

Standardize tool versions: Use SLT-managed versions of Commander, Simplicity Device Manager (SDM), Java, SLC CLI, CMake, Ninja, and GNU Compiler Collection (GCC) for project workflows.
Prioritize SLT-managed paths: Place SLT-managed paths earlier in PATH to avoid accidentally using older or global versions.
Avoid global tool assumptions: Do not rely on globally installed software when project-specific SLT-managed versions are available.
Use activation scripts: Use project-specific activation scripts, especially in multi-version setups.
Use explicit CI/CD paths: Use exact tool paths or project activation scripts in pipelines to ensure reproducible builds.
Log tool versions: Print active tool paths and versions in CI logs to simplify troubleshooting.
Control the environment: Keep the environment project-controlled to reduce version conflicts.

Multi-Version Tool Usage#

Multiple installed versions are common when maintaining released products while developing new ones.

Recommended pattern:

product-v1/
  pkg.slt
  pkg.lock
  user.slconf
  activate-slt-env.bat

product-v2/
  pkg.slt
  pkg.lock
  user.slconf
  activate-slt-env.batproduct-v1/
  pkg.slt
  pkg.lock
  user.slconf
  activate-slt-env.bat

product-v2/
  pkg.slt
  pkg.lock
  user.slconf
  activate-slt-env.bat

Each branch or project should own:

pkg.slt
pkg.lock
user.slconf
activation script
CI setup scriptpkg.slt
pkg.lock
user.slconf
activation script
CI setup script

Do not rely on one global PATH to support every product branch.

Example Workflows for SLT/SLC Environment Management#

The examples below use generic placeholders.


Placeholder	Description
`<ENV_ROOT>`	Folder containing `pkg.slt`, `pkg.lock`, `user.slconf`, and `autogen/`.
`<PROJECT_SLCP>`	Full path to the application `.slcp` file.
`<GCC_BIN_PATH>`	Folder containing `arm-none-eabi-gcc.exe`.
`<SLC_BIN_PATH>`	Folder containing `slc.exe`.
`<JAVA_BIN_PATH>`	Folder containing `java.exe`.
`<CMAKE_BIN_PATH>`	Folder containing `cmake.exe`.
`<NINJA_BIN_PATH>`	Folder containing `ninja.exe`.
`<COMMANDER_BIN_PATH>`	Folder containing `commander.exe`.
`<SDM_BIN_PATH>`	Folder containing `sdm.exe`.

Workflow 1: First-Time Setup with SLT#

Use this workflow when setting up a machine where only SLT is installed manually.

Example pkg.slt:

version = "0"

[dependency]
simplicity-sdk = "~"
slc-cli = "~"
gcc-arm-none-eabi = "~"
cmake = "~"
ninja = "~"
commander = "~"
sdm = "~"version = "0"

[dependency]
simplicity-sdk = "~"
slc-cli = "~"
gcc-arm-none-eabi = "~"
cmake = "~"
ninja = "~"
commander = "~"
sdm = "~"

Run:

cd <ENV_ROOT>
slt --version
slt install -f pkg.sltcd <ENV_ROOT>
slt --version
slt install -f pkg.slt

Expected result:

pkg.slt
pkg.lock
autogen/pkg.slt
pkg.lock
autogen/

pkg.slt defines the requested packages. pkg.lock records the exact resolved versions and should be used for reproducible setup.

Workflow 2: Reproduce an Environment from `pkg.lock`#

Use this workflow when another developer machine or CI runner needs the same environment.

cd <ENV_ROOT>
slt install -f pkg.lockcd <ENV_ROOT>
slt install -f pkg.lock

Validate installed tool versions:

slc --version
java --version
arm-none-eabi-gcc --version
cmake --version
ninja --version
commander --version
sdm --versionslc --version
java --version
arm-none-eabi-gcc --version
cmake --version
ninja --version
commander --version
sdm --version

Check which tool paths are active.

For Windows:

where slc
where java
where arm-none-eabi-gcc
where cmake
where ninja
where commander
where sdmwhere slc
where java
where arm-none-eabi-gcc
where cmake
where ninja
where commander
where sdm

For macOS / Linux:

which slc
which java
which arm-none-eabi-gcc
which cmake
which ninja
which commander
which sdmwhich slc
which java
which arm-none-eabi-gcc
which cmake
which ninja
which commander
which sdm

You can also use SLT to find package locations that were installed by SLT:

slt where <tool-or-package-name>slt where <tool-or-package-name>

Ensure that the highest-priority executable path returned by where on Windows or which on macOS/Linux for slc, java, and arm-none-eabi-gcc points to the SLT-managed installation directory.

If an older Java, SLC, or compiler path appears first, move the SLT-managed path higher in the user PATH, or use a project-specific activation script.

Workflow 3: Project-Specific PATH Activation#

Use this workflow when multiple versions of Java, SLC, GCC, Commander, SDM, or SDKs are installed.

A project-specific activation script avoids relying on one global PATH for every project. Each project can activate the exact tool versions required by its own pkg.lock and configuration files.

Windows: activate-slt-env.bat

@echo off

set "SLC_BIN=<SLC_BIN_PATH>"
set "JAVA_BIN=<JAVA_BIN_PATH>"
set "GCC_ARM_BIN=<GCC_BIN_PATH>"
set "CMAKE_BIN=<CMAKE_BIN_PATH>"
set "NINJA_BIN=<NINJA_BIN_PATH>"
set "COMMANDER_BIN=<COMMANDER_BIN_PATH>"
set "SDM_BIN=<SDM_BIN_PATH>"

set "PATH=%SLC_BIN%;%JAVA_BIN%;%GCC_ARM_BIN%;%CMAKE_BIN%;%NINJA_BIN%;%COMMANDER_BIN%;%SDM_BIN%;%PATH%"

where slc
where java
where arm-none-eabi-gcc
where cmake
where ninja
where commander
where sdm@echo off

set "SLC_BIN=<SLC_BIN_PATH>"
set "JAVA_BIN=<JAVA_BIN_PATH>"
set "GCC_ARM_BIN=<GCC_BIN_PATH>"
set "CMAKE_BIN=<CMAKE_BIN_PATH>"
set "NINJA_BIN=<NINJA_BIN_PATH>"
set "COMMANDER_BIN=<COMMANDER_BIN_PATH>"
set "SDM_BIN=<SDM_BIN_PATH>"

set "PATH=%SLC_BIN%;%JAVA_BIN%;%GCC_ARM_BIN%;%CMAKE_BIN%;%NINJA_BIN%;%COMMANDER_BIN%;%SDM_BIN%;%PATH%"

where slc
where java
where arm-none-eabi-gcc
where cmake
where ninja
where commander
where sdm

Run:

cd <ENV_ROOT>
activate-slt-env.batcd <ENV_ROOT>
activate-slt-env.bat

macOS / Linux: activate-slt-env.sh

#!/usr/bin/env bash
set -e

export SLC_BIN="<SLC_BIN_PATH>"
export JAVA_BIN="<JAVA_BIN_PATH>"
export GCC_ARM_BIN="<GCC_BIN_PATH>"
export CMAKE_BIN="<CMAKE_BIN_PATH>"
export NINJA_BIN="<NINJA_BIN_PATH>"
export COMMANDER_BIN="<COMMANDER_BIN_PATH>"
export SDM_BIN="<SDM_BIN_PATH>"

export PATH="$SLC_BIN:$JAVA_BIN:$GCC_ARM_BIN:$CMAKE_BIN:$NINJA_BIN:$COMMANDER_BIN:$SDM_BIN:$PATH"

which slc
which java
which arm-none-eabi-gcc
which cmake
which ninja
which commander
which sdm#!/usr/bin/env bash
set -e

export SLC_BIN="<SLC_BIN_PATH>"
export JAVA_BIN="<JAVA_BIN_PATH>"
export GCC_ARM_BIN="<GCC_BIN_PATH>"
export CMAKE_BIN="<CMAKE_BIN_PATH>"
export NINJA_BIN="<NINJA_BIN_PATH>"
export COMMANDER_BIN="<COMMANDER_BIN_PATH>"
export SDM_BIN="<SDM_BIN_PATH>"

export PATH="$SLC_BIN:$JAVA_BIN:$GCC_ARM_BIN:$CMAKE_BIN:$NINJA_BIN:$COMMANDER_BIN:$SDM_BIN:$PATH"

which slc
which java
which arm-none-eabi-gcc
which cmake
which ninja
which commander
which sdm

Make the script executable:

chmod +x activate-slt-env.shchmod +x activate-slt-env.sh

Run:

cd <ENV_ROOT>
source ./activate-slt-env.shcd <ENV_ROOT>
source ./activate-slt-env.sh

Workflow 4: Generate an SLC Project#

Use this workflow after SLT has installed the required SDK and tools.

Example user.slconf:

include = [ "autogen/pkg.slconf" ]

[slc]
output-type = [ "cmake" ]include = [ "autogen/pkg.slconf" ]

[slc]
output-type = [ "cmake" ]

Generate the project:

cd <ENV_ROOT>
slc generate <PROJECT_SLCP> --slt-config user.slconf -d generatedcd <ENV_ROOT>
slc generate <PROJECT_SLCP> --slt-config user.slconf -d generated

Expected generated files may include:

generated/cmake_gcc/CMakeLists.txt
generated/cmake_gcc/CMakePresets.json
generated/cmake_gcc/toolchain.cmake
generated/cmake_gcc/autogen_toolchain.cmakegenerated/cmake_gcc/CMakeLists.txt
generated/cmake_gcc/CMakePresets.json
generated/cmake_gcc/toolchain.cmake
generated/cmake_gcc/autogen_toolchain.cmake

Workflow 5: Configure and Build the Generated CMake Project#

For embedded ARM projects, use the generated CMake preset instead of a generic CMake command.

List available presets:

cmake --list-presets -S generated/cmake_gcccmake --list-presets -S generated/cmake_gcc

Example output:

Available configure presets:

  "project" - Configure <project-name>Available configure presets:

  "project" - Configure <project-name>

Configure:

cmake --preset project -S generated/cmake_gcccmake --preset project -S generated/cmake_gcc

Build:

cmake --build generated/cmake_gcc/buildcmake --build generated/cmake_gcc/build

Successful build example:

[68/68] Linking C executable base/<project-name>.out[68/68] Linking C executable base/<project-name>.out

Avoid this generic command for embedded ARM builds:

cmake -S generated/cmake_gcc -B build -G Ninjacmake -S generated/cmake_gcc -B build -G Ninja

It may cause CMake to treat arm-none-eabi-gcc as a native Windows compiler for Windows users.

Workflow 6: CI Setup#

Use the following workflow in your Continuous Integration (CI) pipeline to ensure a consistent, reproducible, and version-controlled development environment across all build executions.

cd <CI_WORKSPACE>
slt install -f pkg.lockcd <CI_WORKSPACE>
slt install -f pkg.lock

After the installation completes successfully, verify that the required tools are installed correctly and available in the system path.

For Windows OS:

where slc
where java
where arm-none-eabi-gcc
where cmake
where ninjawhere slc
where java
where arm-none-eabi-gcc
where cmake
where ninja

For MacOS / Linux:

which slc
which java
which arm-none-eabi-gcc
which cmake
which ninjawhich slc
which java
which arm-none-eabi-gcc
which cmake
which ninja

Generate the project build files using the SLT configuration:

slc generate <PROJECT_SLCP> --slt-config user.slconf -d generatedslc generate <PROJECT_SLCP> --slt-config user.slconf -d generated

Configure and build the project using CMake:

cmake --list-presets -S generated/cmake_gcc
cmake --preset project -S generated/cmake_gcc
cmake --build generated/cmake_gcc/buildcmake --list-presets -S generated/cmake_gcc
cmake --preset project -S generated/cmake_gcc
cmake --build generated/cmake_gcc/build

This workflow ensures that all build dependencies are provisioned from the locked package manifest (pkg.lock), enabling deterministic builds and consistent build results across CI environments.

Recommended CI checks:

Always install from pkg.lock.
Print tool paths and versions in logs.
Fail the build if required tools are missing.
Avoid machine-global tool assumptions.
Use generated CMake presets for embedded builds.

Troubleshooting Common Issues#

Java or SLC Version Conflict#

Check active paths and versions.

For Windows:

where java
where slc
java --version
slc --versionwhere java
where slc
java --version
slc --version

For macOS / Linux:

which java
which slc
java --version
slc --versionwhich java
which slc
java --version
slc --version

If the first path is not SLT-managed, move the SLT-managed path earlier in PATH, or use activate-slt-env.bat / activate-slt-env.sh.

Missing Compiler Error#

Error:

No CMAKE_C_COMPILER could be found.
No CMAKE_CXX_COMPILER could be found.
No CMAKE_ASM_COMPILER could be found.No CMAKE_C_COMPILER could be found.
No CMAKE_CXX_COMPILER could be found.
No CMAKE_ASM_COMPILER could be found.

This usually means the ARM GCC toolchain is not available in the current shell PATH, or CMake has cached a failed compiler detection result.

Fix for Windows:

# Check whether the compiler is available:
where arm-none-eabi-gcc

# Temporarily add the SLT-managed GCC path:
set "PATH=<GCC_BIN_PATH>;%PATH%"

# Verify:
where arm-none-eabi-gcc
arm-none-eabi-gcc --version

# Then clean and retry:
rmdir /s /q generated\cmake_gcc\build
cmake --preset <project> -S generated\cmake_gcc
cmake --build generated\cmake_gcc\build# Check whether the compiler is available:
where arm-none-eabi-gcc

# Temporarily add the SLT-managed GCC path:
set "PATH=<GCC_BIN_PATH>;%PATH%"

# Verify:
where arm-none-eabi-gcc
arm-none-eabi-gcc --version

# Then clean and retry:
rmdir /s /q generated\cmake_gcc\build
cmake --preset <project> -S generated\cmake_gcc
cmake --build generated\cmake_gcc\build

Fix for macOS / Linux:

# Check whether the compiler is available:
which arm-none-eabi-gcc

# Temporarily add the SLT-managed GCC path:
export PATH="<GCC_BIN_PATH>:$PATH"

# Verify:
which arm-none-eabi-gcc 
arm-none-eabi-gcc --version

# Then clean and retry:
rm -rf generated/cmake_gcc/build 
cmake --preset <project> -S generated/cmake_gcc 
cmake --build generated/cmake_gcc/build# Check whether the compiler is available:
which arm-none-eabi-gcc

# Temporarily add the SLT-managed GCC path:
export PATH="<GCC_BIN_PATH>:$PATH"

# Verify:
which arm-none-eabi-gcc 
arm-none-eabi-gcc --version

# Then clean and retry:
rm -rf generated/cmake_gcc/build 
cmake --preset <project> -S generated/cmake_gcc 
cmake --build generated/cmake_gcc/build

CMake Preset File Not Found#

Error:

Could not read presets from <ENV_ROOT>
File not found: <ENV_ROOT>/CMakePresets.jsonCould not read presets from <ENV_ROOT>
File not found: <ENV_ROOT>/CMakePresets.json

Cause:

CMakePresets.json is under generated/cmake_gcc, not the current folder.

Fix:

cmake --list-presets -S generated/cmake_gcc
cmake --preset project -S generated/cmake_gcc
cmake --build generated/cmake_gcc/buildcmake --list-presets -S generated/cmake_gcc
cmake --preset project -S generated/cmake_gcc
cmake --build generated/cmake_gcc/build

Cross-Compiler Treated as a Native Windows Compiler#

Error may include:

arm-none-eabi/bin/ld.exe: unrecognized option '--major-image-version'
-lkernel32 -luser32arm-none-eabi/bin/ld.exe: unrecognized option '--major-image-version'
-lkernel32 -luser32

Cause:

CMake is treating the ARM embedded compiler as a Windows desktop compiler for Windows users.

Fix:

Use the generated CMake preset:

cmake --preset <project> -S generated/cmake_gcc
cmake --build generated/cmake_gcc/buildcmake --preset <project> -S generated/cmake_gcc
cmake --build generated/cmake_gcc/build

Note: To list the available presets, see Workflow 5: Configure and Build the Generated CMake Project.

Recommended Environment Management Pattern#

Install only SLT manually.
Use SLT to install SDKs and tools.
Commit pkg.slt and pkg.lock.
Reproduce environments by using pkg.lock.
Use user.slconf to include autogen/pkg.slconf.
Verify active tools by using where (Windows) or which (macOS/Linux).
Prefer project-specific activation scripts for multi-version setups.
Generate projects by using slc generate.
Build embedded projects by using generated CMake presets.
Avoid relying on machine-global PATH in CI.

Environment Management Using Lock and Configuration Files#

Clean Environment Setup#

Recommended Repository Layout#

Recreating Environments from Lock and Configuration Files#

Version Conflicts#

Multi-Version Tool Usage#

Example Workflows for SLT/SLC Environment Management#

Workflow 1: First-Time Setup with SLT#

Workflow 2: Reproduce an Environment from pkg.lock#

Workflow 3: Project-Specific PATH Activation#

Workflow 4: Generate an SLC Project#

Workflow 5: Configure and Build the Generated CMake Project#

Workflow 6: CI Setup#

Troubleshooting Common Issues#

Java or SLC Version Conflict#

Missing Compiler Error#

CMake Preset File Not Found#

Cross-Compiler Treated as a Native Windows Compiler#

Recommended Environment Management Pattern#

Workflow 2: Reproduce an Environment from `pkg.lock`#