The XCDL.py Tools Reference
This page defines the available XCDL Tools.
The xcdlBuild command line tool
Purpose
This tool builds the artefact for a given XCDL configuration.
Syntax
On Posix systems, this tool can be invoked as a shell script:
sh xcdlBuild.sh [options] [all|clean]
The accepted options are:
- -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.
- -b, --build_config
- 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_dir
- the relative/absolute path to the output folder, where the build configurations will be created (optional, default is build in the current folder).
- --linearise
- --no-linearise
- linearise the build subfolder to shorten the path (default is true).
- -v, --verbose
- print progress output; more occurences increase verbosity.
- -h, --help
- print the list of accepted parameters.
Description
This tool takes a list of repositories and, for a given configuration, creates the build folders, populates them with the dynamically generated headers and all related make files, and runs make on them
During the build process, 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, so the repositories positions should not be changed between 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 needed, it might be useful to get rid of the additional hierarchy, and linearise the build subfolder. This can be done 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).
If the build folder does not exist, it is created.
Examples
sh xcdl-python.git/scripts/xcdlBuild.sh \ --repository="micro-os-plus-second.git/packages" \ --build_config=... \ --verbose
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 tool takes a configuration file, a list of repositories and, for a given configuration, creates the build folders and populates them with the dynamically generated headers and all related Make files.
During the build process, 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, so the repositories positions should not be changed between 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 needed, it might be useful to get rid of the additional hierarchy, and linearise the build subfolder. This can be done 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).
Usually the component repositories are referred in the configuration files, so there is no need to explicitly use the --repository when calling this tool.
If the build folder does not exist, it is created.
Examples
sh xcdl-python.git/scripts/configMakefiles.sh \ --config="micro-os-plus-second.git/packages/portable/devices/debug/tests/conversions/meta/config.py" \ --id=config.os.portable.devices.debug.tests.conversions.osx.cl-sjlj.debug \ --build="build" --linearise --verbose
