Command Reference

This section contains detailed usage information for the SNAPbuild command-line tool.


snapbuild <snappy_file> --module-type <type> --core-version <version> [options]

Positional Arguments

Path and name of the SNAPpy script (.py file) to build


Module Type

-m <type>, --module-type <type>

Required The SNAP module <type> represents the piece of hardware that SNAP is running on. There are differences between the various SNAP modules that require changes in the compiled .spy files, so it is important that the --module-type parameter is correct. Some valid example values for <type> are RF100, RF200PF1, and SM220UF1; for a full list of supported module types, use the --help flag with SNAPbuild and look at the supported module/core combinations table.

SNAPcore Version

-c <version>, --core-version <version>

Required The <version> is used to designate the SNAPcore firmware version of the module that the script is being compiled for.


-h, --help

The --help option displays a help message with a list of the command-line arguments, a collection useful example commands, and a table that shows which module types are supported by each available core version. In the usage information (the first line of help output), options enclosed in [square brackets] are optional, and all other options are required.


-V, --version

The --version flag displays the version of SNAPbuild that is running.


-v, -vv, -vvv, --verbose

Adding the --verbose flag increases the verbosity of SNAPbuild output information. Each --verbose or -v flag increases the verbosity level by one, and can be stacked together like -vvv.

Platform Constant

-p <constant>, --platform <constant>

The platform <constant> is used for compile-time decision-making in SNAPpy scripts. See the “Cross-Platform Coding and Easy Pin Numbering” section in the SNAP Users Guide for examples of how to make use of the platform <constant>.

By default, the --platform <constant> value is set based on the value for --module-type.

Output File Path

-o <path>, --output <path>

Using the --output <path> option allows .spy and .map files to be saved to non-default locations with non-default filenames. Without an --output <path> set, SNAPbuild will save a .spy and .map file with the same name as the SNAPpy .py file to the current directory. For example, building a SNAPpy file named will result in a MyScript.spy file and a in the current directory. The --output option takes a filename or filepath, without the need for a .spy extension.


If the --c-headers flag is present, the name of the directory generated is based on the value provided for the --output option.

Additional Import Path

-I <path>, --Include <path>

Additional SNAPpy script import <path> can be added using the --Include option. When a SNAPpy script contains a line like from MyModule import * then SNAPbuild will search for MyModule in the directory where the SNAPpy .py file resides and any directory included using the --Include option.

Test Script


If the --dry-run flag is present, no output files will be created. This is useful for testing scripts for errors without having to build .spy or .map files.


If the --c-headers flag is present, the directory for c-headers will still be generated.

Generate C-Headers Directory


If the --c-headers flag is present, SNAPbuild will create a build directory with header files used in compiling C code in SNAPpy scripts. The directory name will depend on the input SNAPpy script name or the --output parameter, if provided.

Control Behavior of Linter Errors

Linter errors are caused by scripts which are technically valid SNAPpy code, but are probably not the behavior you want. For example, the following script would trigger a linter error because the assignment of the (globally declared) MY_VAR inside my_function would actually create a local variable (also named MY_VAR):

MY_VAR = 42

def my_function():
    MY_VAR = 12

This is valid Python/SNAPpy code, but it probably isn’t the intended behavior, so by default SNAPbuild will raise an error when you attempt to build a script like this.

The following options can be used to suppress or only warn about these types of errors. (You may wish to suppress or warn on these errors if you have multiple libraries imported, and one of those libraries has defined globals whose names conflict with locals in other libraries.)


If the -w flag is present, SNAPbuild will suppress messages about linter errors, and the script will continue to build.


If the -Wall flag is present, SNAPbuild will emit warnings about linter errors, and the script will continue to build.


If the -Werror flag is present, SNAPbuild will raise linter errors and fail to build the script. (This is the default behavior.)