Overview​

Manifests are XML files that tell the Project Creator and Library Manager how to discover the list of available boards, example projects, libraries and library dependencies. There are several manifest files.

  • The "super-manifest" file contains a list of URLs that software uses to find the board, code example, and middleware manifest files.

  • The "app-manifest" file contains a list of all code examples that should be made available to the user.

  • The "board-manifest" file contains a list of the boards that should be presented to the user in the new project creation tool as well as the list of BSP packages that are presented in the Library Manager tool. There is also a separate BSP dependencies manifest that lists the dependent libraries associated with each BSP.

  • The "middleware-manifest" file contains a list of the available middleware (libraries). Each middleware item can have one or more versions of that middleware available. There is also a separate middleware dependencies manifest that lists the dependent libraries associated with each middleware library.

There are two versions of manifest files: ones for earlier versions of ModusToolbox™ software (2.1 and earlier), and one for newer versions of ModusToolbox™ (2.2 and later, aka "fv2"). The older super-manifest file for use with earlier versions contains only references manifests that contain items that support the older ModusToolbox™ flow. The newer super-manifest file for use with the ModusToolbox™ 2.2 release and later contains references to all the manifest files.


../figures/image26.png

Create your own manifest​

By default, the ModusToolbox™ tools look for our manifest files maintained on our server. So, the initial lists of BSPs, code examples, and middleware available to use are limited to our manifest files. You can create your own manifest files on your servers or locally on your machine, and you can override where ModusToolbox™ tools look for manifest files.

To use your own examples, BSPs, and middleware, you need to create manifest files for your content and a super-manifest that points to your manifest files. To see examples of the syntax of super-manifest and manifest files, you can look at files provided on GitHub:

Make sure you look at the "fv2" manifest files if you are using the flow for ModusToolbox™ version 2.2 and later.

Note:

You can point to local super-manifest and manifest files by using file:/// with the path instead of https://. For example: file:///C:/MyManifests/my-super-manifest.xml

The manifest system is flexible, and there are multiple paths you can follow to customize the manifests.

  • You can create supplementary super-manifest files that identify additional content. The tools will merge your additional content with the default super-manifest.

  • You can replace the default super-manifest file used by the tools.

Supplementing super-manifest using manifest.loc​

In addition to the standard super-manifest file, you can specify "custom" super-manifest files. This allows you to add additional items (BSPs, code examples, libraries) along with the standard items. You can do this by creating a

manifest.loc

file in a hidden subdirectory in your home directory named ".

modustoolbox

":

<user_home>/.modustoolbox/manifest.loc

For example, a manifest.loc file may have:

# This points to the IOT Expert template set
https://github.com/iotexpert/mtb2-iotexpert-manifests/raw/master/iotexpert-super-manifest.xml

If this file exists, then each line in the file is treated as the URL to another super-manifest file, which is exactly like the standard super-manifest file. The data from these manifests is combined with data from the standard super-manifest. See the

Conflicting data

section for dealing with conflicts.

Replacing standard super-manifest using variable​

The location of the standard super-manifest file is hard coded into all of the tools. However, you may override this location by setting the

CyRemoteManifestOverride

environment variable. When this variable is set, the tools use the value of this variable as the location of the super-manifest file and the hard-coded location is ignored. This removes all Infineon content from the tools, by default. For example:

CyRemoteManifestOverride=https://myURL.com/mylocation/super-manifest.xml

Processing​

The process for using the manifest files is the same for all tools that use the data:

  • The first level is to access the super-manifest file(s) to obtain a list of manifest files.

  • The second level is to retrieve the manifest data from any packs that were installed.

  • The third level is to retrieve the manifest data from manifest.loc file, if it exists.

All the manifest data is merged into a single global data model in the tool. See the

Conflicting data

section for dealing with conflicts. There is no per-file scoping. All data is merged before it is presented. The combination of a super manifest file and the merging of all of the data allows various contributors, including third-party contributors, to make new data available without requiring coordinated releases between the various contributors.


Image alt text


Conflicting data​

Ultimately, data from all of the super-manifest and manifest files are combined into a single data collection of BSPs, code examples, and middleware. During the collation of this data, there may be conflicting data entries. There are two types of conflicts.

The first kind is a conflict between data that comes from the level 1 primary super-manifest (and linked manifests), data that comes from the level 2 pack manifest, if present, and data that comes from the level 3

manifest.loc

file, if present. In this case, the data in the level 2 pack manifest overrides the data from the level 1 standard super-manifest, and the data in the level 3

manifest.loc

file overrides the data in the level 2 pack manifest. This mechanism allows you to intentionally override data that is in the standard location. In this case, no error or warning is issued. It is a valid use case.

The second kind of conflict is between data coming from the same source (that is, both from primary or both from secondary). In this case, an error message is printed and all pieces of conflicting data are removed from the data model. This is done because in this case, it is not clear which data item is the correct one.

Local content storage​

The Local content storage (LCS) feature provides a command-line tool called lcs-manager-cli that allows you to create your own local, offline content on demand.

For more details, refer to the

LCS Manager CLI user guide

.