Difference between revisions of "The XCDL.py Tools Reference"

From XCDL (eXtensible Component Definition Language) Wiki
Jump to: navigation, search
m (→‎Description)
m (Ilg moved page The XCDL Tools Reference to The XCDL.py Tools Reference without leaving a redirect)
 
(3 intermediate revisions by the same user not shown)
Line 2: Line 2:
  
 
<div class="toclimit-2"> __TOC__ </div>
 
<div class="toclimit-2"> __TOC__ </div>
 +
 +
== 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:
 +
 +
<pre>
 +
sh xcdlBuild.sh [options] [all|clean]
 +
</pre>
 +
 +
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 ===
 +
 +
<pre>
 +
sh xcdl-python.git/scripts/xcdlBuild.sh \
 +
--repository="micro-os-plus-second.git/packages" \
 +
--build_config=... \
 +
--verbose
 +
</pre>
  
 
== The '''configMakefiles''' command line tool ==
 
== The '''configMakefiles''' command line tool ==
Line 48: Line 103:
 
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).  
 
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).
+
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 define the repository folders when calling this tool.
+
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.
 
If the build folder does not exist, it is created.

Latest revision as of 22:25, 17 June 2014

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
Retrieved from "http://xcdl.sourceforge.net/mw/index.php?title=The_XCDL.py_Tools_Reference&oldid=262"