SDK Path Handling#

If you use Silicon Labs Tool (SLT) and the Silicon Labs Configurator command-line interface (SLC-CLI) to develop Silicon Labs applications, many SLC-CLI commands need to know where your software development kit (SDK) is installed. There are several ways to provide this information, but some are more maintainable than others.

This topic explains recommended approaches for handling SDK paths. Whether you are working interactively at the command line or writing automation scripts, these practices make your workflow more portable, maintainable, and resilient to SDK updates.

Let SLT Find the SDK for You#

One of the most useful SLT features is the slt where command. Rather than remembering where an SDK is installed or searching for it every time, you can ask SLT to locate it.

For example:

slt where simplicity-sdk

SLT returns the installation directory of the requested package.

This command is especially useful in scripts because SDK installation locations can vary:

  • Across Windows, Linux, and macOS

  • Across user accounts on the same operating system

  • After a newer SDK version is installed

  • When the SDK cache or installation directory is relocated

When SLT resolves the location, your scripts remain portable and continue to work without modification, wherever the SDK is installed.

Avoid Hardcoding SDK Paths#

When writing automation scripts, it is tempting to specify the SDK location directly.

For example:

SDK_PATH="/home/user/sdk/simplicity_sdk"

A hardcoded path works on your own computer, but it creates maintenance problems. If another developer clones the project, their SDK may be installed somewhere else. After an SDK upgrade, the installation directory may also change.

Instead of assuming where the SDK is located, let SLT resolve it dynamically:

SDK_PATH="$(slt where simplicity-sdk)"

The script then works on any machine where the SDK was installed through SLT, without changes to the script itself.

Resolve the SDK Path Only Once#

If your script performs multiple SLC-CLI operations, you do not need to run slt where repeatedly.

Resolve the SDK location once, near the beginning of the script, and reuse the result.

SDK_PATH="$(slt where simplicity-sdk)"

slc generate app.slcp --sdk "$SDK_PATH"
slc validate app.slcp --sdk "$SDK_PATH"

Resolving the SDK path once has several advantages:

  • The script is easier to read.

  • The SDK location is stored in a single variable.

  • The path is resolved only once.

  • If the script changes later, only one line needs to be updated.

Always Quote SDK Paths#

Many SDK installation paths do not contain spaces, but some do, depending on the operating system and installation location.

For example, on Windows, an SDK might be installed under:

C:\Program Files\SiliconLabs\

Without quotes, the shell treats spaces as argument separators.

Always write:

slc generate app.slcp --sdk "$SDK_PATH"

instead of:

slc generate app.slcp --sdk $SDK_PATH

Quoting variables prevents many difficult-to-diagnose scripting issues.

Verify the SDK Before Starting#

Before running SLC-CLI commands, it is good practice to verify that the SDK was located successfully.

SDK_PATH="$(slt where simplicity-sdk)"

if [ -z "$SDK_PATH" ] || [ ! -d "$SDK_PATH" ]; then
    echo "Simplicity SDK could not be found."
    exit 1
fi

This check lets the script fail immediately with a clear error message rather than producing confusing build errors later.

This verification is especially useful in CI/CD pipelines and shared automation scripts.

Override the SDK Only When Necessary#

Occasionally, you may want to test your project against a different SDK version without changing your workspace configuration.

In those cases, combine slt where with the --sdk option.

SDK_PATH="$(slt where simplicity-sdk)"

slc generate app.slcp --sdk "$SDK_PATH"

Passing the SDK on the command line overrides the configured SDK only for that command.

Your workspace configuration remains unchanged, so you can compare SDK versions or validate a migration without affecting your normal development environment.

Use slt where During Interactive Development#

The slt where command is also useful when you are not writing scripts.

Suppose you want to:

  • Browse the SDK source.

  • Inspect components.

  • Read documentation.

  • Search for examples.

Instead of searching your installation directories, ask SLT where the SDK is installed.

slt where simplicity-sdk

You can also combine the command with other shell commands.

For example:

cd "$(slt where simplicity-sdk)"

This is a quick, reliable way to go directly to the SDK installation directory.

Organize Scripts Clearly#

Well-structured automation scripts are easier to maintain and troubleshoot.

A good pattern is to separate your script into three steps:

  1. Locate the required packages.

  2. Validate that they exist.

  3. Perform the requested operation.

For example:

SDK_PATH="$(slt where simplicity-sdk)"

if [ ! -d "$SDK_PATH" ]; then
    echo "SDK not found."
    exit 1
fi

slc generate app.slcp --sdk "$SDK_PATH"

Keeping these steps separate makes scripts easier to understand and easier to debug.