SLT Configuration File Specification#

This section describes the syntax, implementations, and mechanics of the SLT Configuration Files.

File Naming and Detection#

The file extension will always be *.slconf to avoid clashing with any general conf files on your machine.

When running in a specific folder, the running tool will determine the "most important folder" and find one .slconf file inside that directory to use. If there are multiple .slconf files in the directory and you do not provide any mechanisms to determine which file to use, the tool should error out with a descriptive error message.

The "most important folder" is a tool-defined mechanism but would generally be considered the output or running directory. For example:

  • slc generate would search these directories in order:

    • Optionally, CLI command for the slconf file

    • Generation directory

    • SLCP/SLCW directory

    • Running directory

    • Global location

  • slt install would search these directories in order:

    • Optionally, CLI command for slconf file

    • Output directory

    • Requirements file directory

    • Running directory

    • Global location

File Format#

The SLT configuration files use TOML as the file format. This is a simple data format, encapsulates exactly what you need, supports comments, and is easy to integrate into other tools due to the presence of parsing libraries for each one.

All category keywords should be lowercase, and variable names should use '-' for multi-word commands.

Example of metadata format:

generated slt.slconf (on slt install)

# Structural to file -- always follows prepend rules (i.e the above include is not forgotten or ignored)
include = [ "/Users/enduser/.silabs/slt/global.slconf" ]

# Not a tool -- restricted naming used by SLT core not available to anyone else.
[core]
# Paths are scanned for adapter packs and if so, they're automatically added as apacks
# Otherwise, they are directly added to the searchable paths
# this defines all the tools accessible from SLT
tool-path = [
    "/Users/enduser/.silabs/slt/installs/conan/p/comma295df7a3b5c1f/p/Contents/MacOS",
    "/Users/enduser/.silabs/slt/installs/conan/p/gdb-ac0b16fd5bb046/p/bin",
    "/Users/enduser/.silabs/slt/installs/conan/p/slc-c37f4c94d4b5ca/p",
    "/Users/enduser/.silabs/slt/installs/conan/p/zapeb8c71ee7eb38/p",
]

[slc]
# Adapter pack path variable is no longer required - these are sourced from tool_path
# sdk_packages map to internal "sdk extensions" and a singular "sdk" but are named 
something that makes more sense to users from a UX perspective.
sdk-package-path = [
    "/Users/enduser/.silabs/slt/installs/conan/p/gecko3983180f5a6e7/p", 
    "/Users/enduser/.silabs/slt/installs/conan/p/wisecon37f4c94d4b5ca/p",
    "/Users/enduser/.silabs/slt/installs/conan/p/matter37f4c94d4b5ca/p"
]
exporter-templates = [ "/Users/enduser/.silabs/slt/installs/conan/p/
exporter3983180f5a6e7/p" ]

[toolchain]
gcc = "/Users/enduser/.silabs/slt/installs/conan/p/gccc0b16fd5bb046/p"
llvm = "/Users/enduser/.silabs/slt/installs/conan/p/llvmc0b16fd5bb046/p"

[sdm]
secure-element-firmware = "/Users/enduser/.silabs/slt/installs/conan/p/
secure_el37f4c94d4b5ca/p"

Local SLT Configuration

# Structural to file -- always follows prepend rules (i.e the above include is not forgotten or ignored)
include = [ "autogen/slt.slconf" ]

[core]
hardware = [ "brd4183a" ]
toolchain = [ "gcc" ]

[slc]
# Overrides the list of the exporter templates
exporter-templates = [ "~/project/exporter_templates" ]

# Prepend these options to the arrays
[prepend.slc]
components = [ "some_software_component" ]
output-type = [ "cmake" ]
# This will override the Matter used because SLC will take the first Matter in the list
sdk-package-path = [ "/devel/git/matter/" ]

[sdm]
# Some potential SDM CLI option - may not be real! 
scanned-ports = "44324"

Configuration Syntax#

All Configuration options must be namespaced and the tools will choose the correct options based on the running command. Generally, all options will be either global- or tool-specific, but the tools are allowed to more specifically namespace their options. This specification does not restrict how tools read the namespaced options (i.e., tools are allowed to read options that have different tool or command namespaces). This allows an existing option to be merged into a parent without requiring a change to your configuration files.

Notes:

  • This should be done sparingly and only in cases where the usage is clear.

  • Because every tool defines its own slconf namespace, no single tool can correctly convert a CLI args list into the slconf file format. It is up to you and each tool to know the slconf namespace for a CLI argument.

The option names within a namespace must be global and consistent with the CLI commands. The mechanism for converting from a CLI option to a conf option is defined as follows:

  • Convert the short-name CLI arguments into long names.

  • Determine the conf file namespace for each argument.

  • Drop the initial double dash.

  • Convert the value TOML format.

  • Options specified multiple times for lists should be placed into the same list.

  • For commands that have arguments, replace the space with an equals sign.

  • Place the new command into a namespace.

Example:

mytool --sdk ~/gsdk --foo a --bar=b --bar=c mytool other --bar=monkey

[core]
sdk = "~/gsdk"

[mytool]
foo = "a"
bar = [ "b", "c" ]

// The bar command is a duplicated option with different semantics in the Other command and must have a unique name/namespace in the conf file.
[mytool.other]
bar = "monkey

Reserved Namespaces#

core and slt are reserved for top-level configuration concepts and slt installer concepts, respectively. Otherwise, the top-level keywords should be indicative of the tool itself (e.g., slc for slc_cli, slt, zap, etc.).

The namespace keys are not case-sensitive and will be lower-cased when parsing.

Prepending List Content#

The SLC configuration files will only support prepending to lists using the specialized top-level keyword, sl.prepend.

[slc]
with = [ "brd4204b" ]

[prepend.slc]
with = [ "brd4100a" ]
foo = [ "bar" ]

Configuration File Inheritance#

The SLT Configuration files must support merging preferences from the global files with the local files. The configuration files do not support variable references when defining values because this would require an order-sensitive parser, which makes the complexity too significant for the value added.

The Configuration file will explicitly list every slconf file that is imported using the slt.slconf-import flag. This is an ordered list of configuration files to import.

When slt install runs, it creates an autogen slconf file at <generation-dir>/autogen/. If no user configuration file exists, it also creates a default user slconf file that references the autogen slconf. If the user configuration file already exists, then it notifies you on the command line to add the autogen file to your user slconf file. An example of the default user configuration file is shown below:

Default User Configuration

# Structural to file -- always follows prepend rules (i.e the above include is not forgotten or ignored)
include = [ "autogen/slt_autogen.slconf" ]