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, 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.