Difference between revisions of "The XCDL.py Tools Reference"
m (→Examples) |
m (→Examples) |
||
Line 55: | Line 55: | ||
<pre> | <pre> | ||
− | sh xcdl-python/scripts/configMakefiles.sh \ | + | sh xcdl-python.git/scripts/configMakefiles.sh \ |
− | --config="micro-os-plus- | + | --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 \ | + | --id=config.os.portable.devices.debug.tests.conversions.osx.cl-sjlj.debug \ |
− | --build="build" --linearise --verbose | + | --build="build" --linearise --verbose |
</pre> | </pre> |
Revision as of 15:06, 16 January 2013
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 headers and all related Make files.
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).
Usually the repositories are referred in the configuration files, so there is no need to explicitly define the repository folders 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