ModusToolbox™ build system | ModusToolbox™ ecosystem documentation

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.

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. 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 two separate types: 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. 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 replace a BSP in an application.

Environment variables

ModusToolbox™ software supports custom installation paths, and you can use the Settings tool to set most of them. See the Settings tool user guide for more details. There is one variable that you have to set manually with an environment variable:

CY_TOOLS_PATHS (path to the installation "tools_<version>" directory)

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 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, GCC_ARM, and LLVM_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=APP_KIT_PSC3M5_EVK ignores all TARGET_ directories except TARGET=APP_KIT_PSC3M5_EVK.

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:

Recipe pre-build – Defined using recipe_prebuild target.
BSP pre-build – Defined using bsp_prebuild target.
Project pre-build – Defined using project_prebuild target.
Source compilation and linking.
Recipe post-build – Defined using recipe_postbuild target.
BSP post-build – Defined using bsp_postbuild target.
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.
`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.
`erase`	Erases the MCU's internal flash memory and provides the option to erase any connected external nonvolatile memory. This operation is irreversible. This target performs a mass erase of the device's internal nonvolatile memory, removing firmware including any user data, configuration settings, and calibration data. By default, only internal memory is erased. To include supported external memory (for example, QSPI flash), use `make erase MTB_ERASE_EXT_MEM=1`. Erase is irreversible and may be blocked by device protection or security settings; unlock or clear protection first if required. Ensure there is stable power and do not interrupt the debug session during the operation.
`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.
`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, IAR. Example Usage: `make build TOOLCHAIN=IAR` Supported toolchains for this include GCC_ARM, IAR, ARM and LLVM_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, ../my_source/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_COMPILER_LLVM_ARM_DIR`	Absolute path to the LLVM toolchain directory. Setting this path overrides the default LLVM 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_LLVM_ARM_DIR=C:/Program Files/LLVM` 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.