The XCDL.py Tools Reference

This page defines the available XCDL Tools.

The configMakefiles command line tool

Purpose

This tool generates a full build configuration for a given XCDL configuration.

Syntax

On Posix systems, this tool can be invoked as a shell script:

sh configMakefiles.sh [params]

The accepted parameters are:

• -c, --config

the relative/absolute path to the configuration file. (mandatory).

• -r, --repository

the relative/absolute path to the repository folder; multiple repositories are accepted; normally the repositories are referred in the configuration files and this param is not needed.

• -i, --id

the ID of the configuration to be generated; can be a leaf node or a subtree to create multiple configurations from a single run (mandatory).

• -b, --build

the relative/absolute path to the output folder, where the build configurations will be created (mandatory).

• -t, --toolchain

the ID of the toolchain to be used; overwrite the toolchain refered in the configuration with this one.

• -l, --linearise

linearise the build subfolder to shorten the path (recommended).

• -v, --verbose

print progress output; more occurences increase verbosity.

• -h, --help

print the list of accepted parameters.

Description

This tools takes a configuration file, a list of repositories and, for a given configuration, creates the build folders and populates them with the dynamically generated folders and the Make files.

Usually the repositories are referred in the configuration files, so there is no need to explicitly define the repository folders when calling this tool.

During the build the original repositories are considered read only, and no files are stored there, all temporary files (object files, dependency files) are create in the build folder. However, the source files are referred from their original location, in the repositories, so their position should not be changed during builds.

The result of the build is a binary file for embedded platforms, or an executable file for synthesised platforms.

If the buildFolder definition is used in the configuration file, this subfolder is created in the build folder, so multiple build configurations can be created in a single build folder (for example Debug/Release).

For complex situations, with multiple tests generated in a single build folder, the buildFolder definition can be hierarchical, with multiple subfolders, finally ending in Debug/Release (for example osx/cl-sjlj/debug/conversions/Debug).

When only a subset of the tests are generated, it might be useful to get rid of the additional hierarchy, and linearise the build subfolder, by adding the --linearise option. The effect is to dynamically change the buildFolder definition and replace all folder separators with underscores (for the above example the result would be osx_cl-sjlj_debug_conversions_Debug, a bit too long but slightly easier to identify than 5 subfolders in a file explorer).