ModusToolbox™ build system

This chapter covers various aspects of the ModusToolbox™ build system. Refer to

CLI set-up instructions

for getting started information about using the command line tools. This chapter is organized as follows:

• Overview

• make help

• make getlibs

• BSPs

• Environment variables

• Adding source files

• Pre-builds and post-builds

• Available make targets

• Available make variables

Overview

The ModusToolbox™ build system is based on GNU make. It performs application builds and provides the logic required to launch tools and run utilities. It consists of a light and accessible set of Makefiles deployed as part of every application. This structure allows each application to own the build process, and it allows environment-specific or application-specific changes to be made with relative ease. The system runs on any environment that has the make and git utilities.

Note:

User-defined command line make parameters are not supported and the only supported variables are TOOLCHAIN and TARGET.

The ModusToolbox™ command line interface (CLI) and supported IDEs all use the same build system. Hence, switching between them is fully supported. Program/Debug and other tools can be used in either the command line or an IDE environment. In all cases, the build system relies on the presence of ModusToolbox™ tools included with the ModusToolbox™ installer.

The tools contain a

start.mk

file that serves as a reference point for setting up the environment before executing the recipe-specific build in the base library. The file also provides a

getlibs

make target that brings libraries into an application. Every application must then specify a target board on which the application will run. These are provided by the

<BSP>.mk

files deployed as a part of a BSP library.

The majority of the

Makefiles

are deployed as git repositories (called "repos"), in the same way that libraries are deployed in the ModusToolbox™ software. There are two separate repos: core-make used by all recipes and a recipe-make-xxx that contains BSP/target specific details. These are the minimum required to enable an application build. Together, these

Makefiles

form the build system.

make help

The ModusToolbox™ build system includes a

make help

target that provides help documentation. In order to use the help, you must first run the

make getlibs

command in an application directory (see

make getlibs

for details). From the appropriate shell in an application directory, type in the following to print the available make targets and variables to the console:

make help

To view verbose documentation for any of these targets or variables, specify them using the

CY_HELP

variable. For example:

make help CY_HELP=TOOLCHAIN

Note:

This help documentation is part of the base library, and it may also contain additional information specific to a BSP.

make getlibs

When you run the

make getlibs

command, the build system finds all the .

mtb

files in the application directory and performs

git clone

operations on them. A .

mtb

file contains the source location of a library repo, a specific tag for a version of the code, and the location to store the library.

The

getlibs

target finds and processes all .

mtb

files and uses the

git clone

command to clone or pull the code as appropriate. The target generates .

mtb

files for indirect dependencies. Then, it checks out the specific tag listed in the .

mtb

file. The Project Creator and Library Manager invoke this process automatically.

Note:

ModusToolbox™ version 3.x no longer supports the old LIB flow, thus all .lib files are ignored.

• The

  getlibs

  target must be invoked separately from any other make target (for example, the command

  make getlibs build

  is not allowed and the

  Makefiles

  will generate an error; however, a command such as

  make clean build

  is allowed).

• The

  getlibs

  target performs a

  git fetch

  on existing libraries but will always checkout the tag pointed to by the overseeing .

  mtb

  file.

• The

  getlibs

  target detects if users have modified standard code and will not overwrite their work. This allows you to perform some action (for example commit code or revert changes, as appropriate) instead of overwriting the changes.

The build system also has a

printlibs

target that can be used to print the status of the cloned libraries.

repos

The cloned libraries are located in their individual git repos in the directory pointed to by the

CY_GETLIBS_PATH

variable (for example,

/deps

). These all point to the "our" remote origin. You can point your repo by editing the .

git/config

file or by running the git remote command.

If the repos are modified, add the changes to your source control (git branch is recommended). When

make getlibs

is run (to either add new libraries or update libraries), it requires the repos to be clean (that is, all changes must be committed). You may also use the .

gitignore

file for adding untracked files when running

make getlibs

. See also

KBA231252

.

BSPs

An application must specify a target BSP through the

TARGET

variable in the

Makefile

. We provide BSPs based on our kits to use as a starting point. When you create an application, the selected BSP is then owned by that application, and you can modify it as needed. For more information about BSPs, refer to the

Board support packages

chapter.

• When using the Project Creator to create an application, it provides the selected BSP and updates the

  Makefile

  .

• Use the Library Manager to add, update, or remove a BSP from an application. You can also add a .

  mtb

  file that contains the URL and a version tag of interest in the application.

Environment variables

Note:

In ModusToolbox™ tools package 3.5.0 and later, you can use the Settings tool instead of these environment variables. If these are set, they will be disabled in the Settings tool. See the Settings tool user guide for more details.

ModusToolbox™ software supports custom installation paths, and we provide the following variables to specify locations of tools and support files other than the default:

• CY_TOOLS_PATHS

  (path to the installation "

  tools_<version>

  " directory)

• CyManifestLocOverride

  (path to the local manifest.loc file)

• CyRemoteManifestOverride

  (URL to a specific manifest file)

We also include a global path for assets like device-db using the variable named

CY_GETLIBS_GLOBAL_PATH

. If the variable does not exist, it assumes a default path of

~/.modustoolbox/global

.

Note:

When entering variables that require a path, use a Windows-style path (not Cygwin-style, like /cygdrive/c/). Also, use forward slashes. For example, "C:/MyPath/ModusToolbox/tools_<version>".

Adding source files

Source and header files placed in the application directory hierarchy are automatically added by the auto-discovery mechanism. Similarly, library archives and object files are automatically added to the application. Any object file not referenced by the application is discarded by the linker. The Project Creator and Library Manager tools run the

make getlibs

command and generate a

mtb.mk

file in the application's

libs

subdirectory. This file specifies the location of shared libraries included in the build.

The application Makefile can also include specific source files (

SOURCES

), header file locations (

INCLUDES

) and prebuilt libraries (

LDLIBS

). This is useful when the files are located outside of the application directory hierarchy or when specific sources need to be included from the filtered directories.

Auto-discovery

The build system implements auto-discovery of library files, source files, header files, object files, and pre-built libraries. If these files follow the specified rules, they are guaranteed to be brought into the application build automatically. Auto-discovery searches for all supported file types in the application directory hierarchy and performs filtering based on a directory naming convention and specified directories, as well as files to ignore. If files external to the application directory hierarchy need to be added, they can be specified using the

SOURCES

,

INCLUDES

, and

LIBS

make variables.

To control which files are included/excluded, the build system implements a filtering mechanism based on directory names and .

cyignore

files.

.cyignore

Prior to applying auto-discovery and filtering, the build system will first search for .

cyignore

files in the roots of applications/projects, libraries, and BSPs, and construct a set of directories and files to exclude. This can be used to skip searching directories that contain no source code, or skip source code you don't want included. As an example, many ModusToolbox™ BSPs and libraries contain a directory named

docs

in the root directory, which contains no source code. So to speed up auto-discovery, these BSPs and middleware libraries include a .

cyignore

file that contains a line

docs

, which causes auto-discovery to ignore that directory. The system will only detect .

cyignore

files in the application/project root, as well as in the roots of libraries and BSPs, so there is not a recursive search.

All paths inside a .

cyignore

file are relative to the location of that specific .

cyignore

file. You could use

keep/all/except

if you wanted to keep "all" but exclude "except." You also can use "../" to look up and out from the current directory.

As mentioned, some library might contain source code that you do not want added to your build. Specifying that directory's location would require hard-coding the version of the library in use, which could potentially cause problems later. In this case, the variable

$(SEARCH_

library

)

solves this problem. For example, if the bluetooth-freertos library contains a directory named

firmware_deprecated

, you could add the following to the .

cyignore

file in the application root directory to exclude it:

$(SEARCH_bluetooth-freertos)/firmware_deprecated/

This causes that directory inside the bluetooth-freertos library to be ignored no matter where it is inside the workspace.

Another useful feature in a .

cyignore

file is a comment line. Any line that starts with "#" is skipped. So, you could write a description about why a file or directory is to be excluded. Or, you could just comment out an entry to assist in debugging your application.

Note:

Wildcards and expressions are not allowed, and each directory or file requires its own entry in the file. However, the .

cyignore

file can contain make variables, such as

SEARCH

as shown above.

The

CY_IGNORE

variable can also be used in the

Makefile

to define directories and files to exclude.

Note:

The CY_IGNORE variable should contain paths that are relative to the application root. For example, ./src1.

TOOLCHAIN_<NAME>

Any directory that has the prefix "TOOLCHAIN_" is interpreted as a directory that is toolchain specific. The "NAME" corresponds to the value stored in the

TOOLCHAIN

make variable. For example, an IAR-specific set of files is located under a directory named

TOOLCHAIN_IAR

. Auto-discovery only includes the

TOOLCHAIN_<NAME>

directories for the specified

TOOLCHAIN

variable. All others are ignored. ModusToolbox™ supports IAR, ARM, and GCC_ARM.

TARGET_<NAME>

Any directory that has the prefix "TARGET_" is interpreted as a directory that is target specific. The "NAME" corresponds to the value stored in the

TARGET

make variable. For example, a build with

TARGET=CY8CPROTO-062-4343W

ignores all

TARGET_

directories except

TARGET_CY8CPROTO-062-4343W

.

Note:

The TARGET_ directory is often associated with the BSP, but it can be used in a generic sense. For example, if application sources need to be included only for a certain

TARGET

, this mechanism can be used to achieve that.

Note:

The output directory structure includes the TARGET name in the path, so you can build for target A and B and both artifact files will exist on disk.

CONFIG_<NAME>

Any directory that has the prefix "CONFIG_" is interpreted as a directory that is configuration (Debug/Release) specific. The "NAME" corresponds to the value stored in the

CONFIG

make variable. For example, a build with

CONFIG=CustomBuild

ignores all

CONFIG_

directories, except

CONFIG_CustomBuild

.

Note:

The output directory structure includes the CONFIG name in the path, so you can build for config A and B and both artifact files will exist on disk.

COMPONENT_<NAME>

Any directory that has the prefix "COMPONENT_" is interpreted as a directory that is component specific. This is used to enable/disable optional code. The "NAME" corresponds to the value stored in the

COMPONENT

make variable. For example, consider an application that sets

COMPONENTS+=comp1

. Also assume that there are two directories containing component-specific sources:

COMPONENT_comp1/src.c
COMPONENT_comp2/src.c

Auto-discovery will only include

COMPONENT_comp1/src.c

and ignore

COMPONENT_comp2/src.c

. If a specific component needs to be removed, either delete it from the

COMPONENTS

variable or add it to the

DISABLE_COMPONENTS

variable.

BSP makefile

Auto-discovery will also search for a

bsp.mk

file (aka, BSP makefile). If no matching BSP makefile is found, it will fail to build.

Pre-builds and post-builds

A pre-build or post-build operation is typically a script file invoked by the build system. Such operations are possible at several stages in the build process. They can be specified at the application, BSP, and recipe levels.

You can pre-build and post-build arguments in the application Makefile. For example:

project_prebuild:
    command1 -arg1
    Command2 -arg2

The sequence of execution in a build is as follows:

1. Recipe pre-build – Defined using

   recipe_prebuild

   target.

2. BSP pre-build – Defined using

   bsp_prebuild

   target.

3. Project pre-build – Defined using

   project_prebuild

   target.

4. Source compilation and linking.

5. Recipe post-build – Defined using

   recipe_postbuild

   target.

6. BSP post-build – Defined using

   bsp_postbuild

   target.

7. Project post-build – Defined using

   project_postbuild

   target.

Available make targets

A make target specifies the type of function or activity that the make invocation executes. The build system does not support a make command with multiple targets. Therefore, a target must be called in a separate make invocation. The following tables list and describe the available make targets for all recipes.

General make targets

Target	Description
all	Same as build . That is, builds the application. This target is equivalent to the build target.
getlibs	Clones the repositories and checks out the identified commit. When using . mtb files, the repos are cloned to the shared location $(CY_GETLIBS_SHARED_PATH)/$(CY_GETLIBS_SHARED_NAME) . By default, this directory is specified by the project Makefile .
build	Builds the application. The build process involves source auto-discovery, code-generation, pre-builds, and post-builds. For faster incremental builds, use the qbuild target to skip the auto-discovery step. For multi-core applications, running this target builds all core projects in the application, and generates a combined hex file.
build_proj	Build a single project. Build a single target in the application. In single core-applications, this target is the same as the build target.
qbuild	Quick builds the application using the previous build's source list. When no other sources need to be auto-discovered, this target can be used to skip the auto-discovery step for a faster incremental build.
qbuild_proj	Builds a single project using the previous build's source list. In the single project-applications, this target is the same as the qbuild target. When no other sources need to be auto-discovered, this target can be used to skip the auto-discovery step for a faster incremental build.
program	Builds the application and programs it to the target device. In multi-core applications, this will program the combined hex file. The build process performs the same operations as the build target. Upon completion, the artifact is programmed to the board.
program_proj	Build and program only the current project to the target device. In single-core applications, this target is the same as the program target. The build process performs the same operations as the build target. Upon completion, the artifact is programmed to the board.
qprogram	Quick programs a built application to the target device without rebuilding. This target allows programming an existing artifact to the board without a build step.
qprogram_proj	Programs a built project to the target device without rebuilding. In single-core applications, this target is the same as the qprogram target. This target allows programming an existing artifact to the board without a build step.
clean	Cleans the /build/<TARGET> directory. The directory and all its contents are deleted from disk.
help	Prints the help documentation. Use the CY_HELP=<name of target or variable> to see the verbose documentation for a given target or a variable.
prebuild	Generates code for the application. Runs custom prebuild commands to generate source code.

IDE make targets

Target	Description
eclipse	Generates Eclipse IDE launch configs and project files. This target generates a . cproject and a . project if they do not exist in the application root directory.
vscode	Generates VS Code IDE files. This target generates VS Code files for debug/program launches, IntelliSense, and custom tasks. These overwrite the existing files in the application directory except for settings.json .
ewarm / ewarm8	This target generates an IAR Embedded Workbench compatible . ipcf file that can be imported into IAR-EW. The . ipcf file is overwritten every time this target is run. Project generation requires Python 3 to be installed and present in the PATH variable. For applications that were created using core-make-3.0 or older, you must use the make ewarm8 command instead.
uvision / uvision5	Generates a Keil µVision IDE .cprj file. This target generates a CMSIS-compatible file that can be imported into Keil µVision. The file is overwritten every time this target is run. Files in the default cmsis output directory will be automatically excluded when calling make uvision . Project generation requires Python 3 to be installed and present in the PATH variable. For applications that were created using core-make-3.0 or older, you must use the make uvision5 command instead.

Utility make targets

Target	Description
progtool	Performs specified operations on the programmer/firmware-loader. Only available for devices that use KitProg3. This target expects user-interaction on the shell while running it. When prompted, you must specify the command(s) to run for the tool.
printlibs	Prints the status of the library repos. This target parses through the library repos and prints the SHA1 commit. It also shows whether the repo is clean (no changes) or dirty (modified or new files).
check	Checks for the necessary tools. Not all tools are necessary for every build recipe. This target allows you to get an idea of which tools are missing if a build fails in an unexpected way.

Available make variables

The following variables customize various make targets. They can be defined in the application Makefile or passed through the make invocation. The following sections group the variables for how they can be used.

Basic configuration make variables

These variables define basic aspects of building an application. For example:

make build TOOLCHAIN=GCC_ARM CONFIG=CustomConfig -j8

Variable	Description
TARGET	Specifies the target board/kit (that is, BSP). For example, CY8CPROTO-062-4343W. Example usage: make build TARGET=CY8CPROTO-062-4343W
CORE	Specifies the name of the Arm® core for which a project is building (e.g. CM4). Example Usage: make build CORE=CM4 Use this variable to select compiler and linker options to build a project for a specified Arm core.
CORE_NAME	Specifies the name of the on-chip core for which a project is building (e.g. CM7_0). Example Usage: make build CORE_NAME=CM7_0 Use this variable to select compiler and linker options to build a project for a specified on-chip core. This variable is applicable for some multi-core devices only (e.g. XMC7xxx).
APPNAME	Specifies the name of the application. For example, "AppV1" > AppV1.elf. Example usage: make build APPNAME="AppV1" This variable is used to set the name of the application artifact (programmable image). This variable may also be used when generating launch configs when invoking the eclipse target.
TOOLCHAIN	Specifies the toolchain used to build the application. For example, GCC_ARM. Example Usage: make build TOOLCHAIN=IAR Supported toolchains for this include GCC_ARM, IAR, and ARM. When setting TOOLCHAIN=IAR , you should also specify the heap type using LDFLAGS . The --advanced_heap option is required if the program uses a library that requires it.
CONFIG	Specifies the configuration option for the build [Debug Release]. Example Usage: make build CONFIG=Release The CONFIG variable is not limited to Debug/Release. It can be other values. However in those instances, the build system will not configure the optimization flags. Debug=lowest optimization, Release=highest optimization. The optimization flags are toolchain specific. If you go with your custom config, then you can manually set the optimization flag in the CFLAGS .
VERBOSE	Specifies whether the build is silent [false] or verbose [true]. Example Usage: make build VERBOSE=true Setting VERBOSE to true may help in debugging build errors/warnings. By default, it is set to false.

Advanced configuration make variables

These variables define advanced aspects of building an application.

Variable	Description
SOURCES	Specifies C/C++ and assembly files outside of application directory. Example Usage (within Makefile ): SOURCES+=path/to/file/Source1.c This can be used to include files external to the application directory. The path can be both absolute or relative to the application directory.
INCLUDES	Specifies include paths outside of the application directory. Example Usage (within Makefile ): INCLUDES+=path/to/headers These MUST NOT have -I prepended. The path can be either absolute or relative to the application directory.
DEFINES	Specifies additional defines passed to the compiler. Example Usage (within Makefile ): DEFINES+=EXAMPLE_DEFINE=0x01 These MUST NOT have -D prepended.
VFP_SELECT	Selects hard/soft ABI or full software for floating-point operations [softfp hardfp softfloat]. If not defined, this value defaults to softfp. Example Usage (within Makefile ): VFP_SELECT=hardfp
VFP_SELECT_PRECISION	Selects single-precision or double-precision operating mode for floating-point operations. If not defined, this value defaults to double-precision. Enable single-precision mode by using the "singlefp" option. Example Usage (within Makefile ): VFP_SELECT_PRECISION=singlefp
CFLAGS	Prepends additional C compiler flags. Example Usage (within Makefile ): CFLAGS+= -Werror -Wall -O2
CXXFLAGS	Prepends additional C++ compiler flags. Example Usage (within Makefile ): CXXFLAGS+= -finline-functions
ASFLAGS	Prepends additional assembler flags. Usage is similar to CFLAGS .
LDFLAGS	Prepends additional linker flags. Example Usage (within Makefile ): LDFLAGS+= -nodefaultlibs
LINKER_SCRIPT	Specifies a custom linker script location. Example Usage (within Makefile ): LINKER_SCRIPT=path/to/file/Custom_Linker1.ld This linker script overrides the default. Additional linker scripts can be added for GCC via the LDFLAGS variable as a -L option.
COMPONENTS	Adds component-specific files to the build. Example Usage (within Makefile ): COMPONENTS+=CUSTOM_CONFIGURATION Create a directory named COMPONENT_<VALUE> and place your files. Then include the corresponding make variable to have that feature library be included in the build. For example, create a directory named COMPONENT_ACCELEROMETER into auto-discovery. Then, add the following make variable to the Makefile : COMPONENT=ACCELEROMETER . If the make variable does not include the <VALUE> , then that library will not be included in the build.
DISABLE_COMPONENTS	Removes component-specific files from the build. Example Usage (within Makefile ): DISABLE_COMPONENTS=BSP_DESIGN_MODUS Include a <VALUE> to this make variable to have that feature library be excluded in the build. For example, to exclude the contents of the COMPONENT_BSP_DESIGN_MODUS directory, set DISABLE_COMPONENTS=BSP_DESIGN_MODUS .
SEARCH	List of paths to include in auto-discovery. For example, ../mtb_shared/lib1 . Example Usage (within Makefile ): SEARCH+=directory_containing_source_files The SEARCH variable can also be used by the application to include other directories to auto-discovery.
SKIP_CODE_GEN	Disables code generation from configurators when building. When set to a non-empty value, the build process will no longer run code generation from configurators.
MERGE	List of projects in the application to generate a combined hex file from. By default, building a multi-project application will generate a combined hex file from its sub-projects. This variable can be set from the application Makefile to override the set of projects to generate combined hex file from.
VCORE_ATTRS	Virtual core attribute. Currently supported values are "TRUSTZONE_SECURE" and "TRUSTZONE_NON_SECURE" which specify the core property for Arm TrustZone.
TRUSTZONE_VENEER	The path of the veneer object file used for Arm TrustZone. When specified for a secure project, it specifies the path of the veneer object file to generated. When specified for a non-secure project, it specifies the path of the veneer object file to include.

BSP make variables

Variable	Description
DEVICE	Device ID for the primary MCU on the target board/kit. Set by bsp.mk . The device identifier is mandatory for all board/kits.
ADDITIONAL_DEVICES	IDs for additional devices on the target board/kit. Set by bsp.mk . These include devices such as radios on the board/kit. This variable is optional.
BSP_PROGRAM_INTERFACE	Specifies the debugging and programming interface to use. The default value and valid values all depend on the BSP. Possible values include KitProg3, JLink, and FTDI. Most BSPs will only support a subset of this list.

Getlibs make variables

These variables are used with the

make getlibs

target.

Note:

When entering variables that require a path, use a Windows-style path (not Cygwin-style, like /cygdrive/c/). Also, use forward slashes. For example, "C:/MyPath/ModusToolbox/tools_<version>."

Variable	Description
MTB_USE_LOCAL_CONTENT	If set to non-empty, enable local content storage. Enable local content storage to allow use of ModusToolbox™ software without requiring internet access. Refer to the LCS Manager CLI User guide for more details.
CY_GETLIBS_PATH	Path to the intended location of libs info directory. The directory contains local libraries and metadata files about shared libraries.
CY_GETLIBS_DEPS_PATH	Path to where the library-manager stores . mtb files. Setting this path allows relocating the directory that the library-manager uses to store the .mtb files in your application. The default location is in a directory named deps.
CY_GETLIBS_SHARED_PATH	Relative path to the shared repo location. All . mtb files have the format, <URI><COMMIT><LOCATION> . If the <LOCATION> field begins with $$ASSET_REPO$$ , then the repo is deposited in the path specified by the CY_GETLIBS_SHARED_PATH variable. The default is set from the project Makefile .
CY_GETLIBS_SHARED_NAME	Directory name of the shared repo location. All . mtb files have the format, <URI><COMMIT><LOCATION> . If the <LOCATION> field begins with $$ASSET_REPO$$ , then the repo is deposited in the directory specified by the CY_GETLIBS_SHARED_NAME variable. By default, this is set from the project Makefile .

Path make variables

These variables are used to specify various paths.

Note:

When entering variables that require a path, use a Windows-style path (not Cygwin-style, like /cygdrive/c/). Also, use forward slashes. For example, "C:/MyPath/ModusToolbox/tools_<version>."

Variable	Description
CY_APP_PATH	Relative path to the top-level of application. For example, ./ Settings this path to other than ./ allows the auto-discovery mechanism to search from a root directory location that is higher than the application directory. For example, CY_APP_PATH=../../ allows auto-discovery of files from a location that is two directories above the location of the Makefile.
CY_COMPILER_GCC_ARM_DIR	Absolute path to the gcc-arm toolchain directory. Setting this path overrides the default GCC_ARM toolchain directory. It is used when the compiler is located at a non-default directory. Make uses this variable for the path to the assembler, compiler, linker, objcopy, and other toolchain binaries. For example, CY_COMPILER_GCC_ARM_DIR=C:/Program Files (x86)GNU arm Embedded Toolchain/10 2021.10 When set in the Makefile , no quotes are required.
CY_COMPILER_IAR_DIR	Absolute path to the IAR toolchain directory. Setting this path overrides the default IAR toolchain directory. It is used when the compiler is located at a non-default directory. Make uses this variable for the path to the assembler, compiler, linker, objcopy, and other toolchain binaries. For example, CY_COMPILER_IAR_DIR=C:/Program Files/IAR Systems/Embedded Workbench 9.1/arm When set in the Makefile , no quotes are required.
CY_COMPILER_ARM_DIR	Absolute path to the ARM toolchain directory. Setting this path overrides the default ARM toolchain directory. It is used when the compiler is located at a non-default directory. Make uses this variable for the path to the assembler, compiler, linker, objcopy, and other toolchain binaries. For example, CY_COMPILER_ARM_DIR=C:/Program Files/ARMCompiler6.16 When set in the Makefile , no quotes are required.
CY_TOOLS_DIR	Absolute path to the tools root directory. Example Usage: make build CY_TOOLS_DIR="path/to/ModusToolbox/tools_x.y" Applications must specify the tools_<version> directory location, which contains the root Makefile and the necessary tools and scripts to build an application. Application Makefiles are configured to automatically search in the standard locations for various platforms. If the tools are not located in the standard location, you may explicitly set this.
CY_BUILD_LOCATION	Absolute path to the build output directory (default: pwd/build ). The build output directory is structured as /TARGET/CONFIG . Setting this variable allows the build artifacts to be located in the directory pointed to by this variable.
CY_PYTHON_PATH	Specifies the path to a specific Python executable. Example Usage: CY_PYTHON_PATH="path/to/python/executable/python.exe" For make targets that depend on Python, the build system looks for Python 3 in the user's PATH and uses that to invoke python. If however CY_PYTHON_PATH is defined, it will use that python executable.
MTB_JLINK_DIR	Specifies the path to the SEGGER J-Link software install directory "JLink". Example Usage: MTB_JLINK_DIR:=C:/Program Files/SEGGER/JLink Setting this path allows the make system to locate the JLink executable when calling make program. If not specified, make will default to the JLink executable in the PATH variable. When generating launch configurations for IDEs, this will override the default J-Link path.

Miscellaneous make variables

These are miscellaneous variables used for various make targets.

Note:

When entering variables that require a path, use a Windows-style path (not Cygwin-style, like /cygdrive/c/). Also, use forward slashes. For example, "C:/MyPath/ModusToolbox/tools_<version>."

Variable	Description
CY_IGNORE	Adds to the directory and file ignore list. For example, ./file1.c ./inc1 Example Usage: make build CY_IGNORE="path/to/file/ignore_file" Directories and files listed in this variable are ignored in auto-discovery. This mechanism works in combination with any existing .cyignore files in the application.
CY_IDE_PRJNAME	This variable contains the name that will be used to create the application name and support files for an IDE during application export. Use this variable to provide a custom name of an application for the IDE during application export. If CY_IDE_PRJNAME is not set on the command line, then APPNAME (which is specified in the Makefile ) is used as the default. This name can be important for some IDEs to set a correct meaningful name for the application, support files, and launch configurations in the IDE.
CY_SIMULATOR_GEN_AUTO	If set to 1, automatically generate a simulator archive (if supported by the target device). When enabled, the build make target will generate a debugging tgz archive for the Infineon online simulator as part of the post-build process.

Tools targets

Note:

There are various targets to launch tools and configurators that are not part of the make system, but they can be used in the application directory. The following table lists a few of the common targets as a convenience. Refer to the applicable user guide for details for the given configurator or tool.

Target	Description
bsp-assistant	Launches the BSP Assistant with the active BSP for the application.
bt-configurator	Launches the Bluetooth® Configurator GUI for the application's cybt file.
capsense-configurator	Launches the CAPSENSE™ Configurator GUI for the target's cycapsense file.
capsense-tuner	Launches the CAPSENSE™ Tuner GUI for the target's cycapsense file.
device-configurator	Launches the Device Configurator on the application's *. modus file.
library-manager	Launches the Library Manager for the application to add/remove libraries and to upgrade/downgrade existing libraries.
lin-configurator	Launches the LIN Configurator GUI for the target's mtblin file.
qspi-configurator	Launches the QSPI Configurator GUI for the target's cyqspi file.
seglcd-configurator	Launches the Segment LCD Configurator GUI for the target's cyseglcd file.
smartio-configurator	Launches the Smart I/O Configurator GUI for the target's modus file.
usbdev-configurator	Launches the USB Configurator GUI for the target's cyusbdev file.