-o

Pathname of the output directory

A directory containing the generated build artifacts, in particular the compiler.opt and linker.cmd files. By default, the output directory has the same name as the configuration script, minus the .cfg extension, within the same parent directory as this script.

-t

Name of the RTSC target module

The name of a RTSC target module to use, for example ti.targets.C64P.

If no config.bld file is given, then this is a required parameter.

If a config.bld file is given then this parameter is optional, and by default the target will be Build.targets[0] from the user's config.bld. If Build.targets contains more than one entry, then this option can be used to override that default.

-c

Root directory of the code generation tools

The path to the installation directory of the compiler and linker for the selected target. The definition of "installation directory" can vary from compiler to compiler, but is most commonly the directory that contains a "bin" subdirectory.

If no config.bld file is given, then this is a required parameter.

If a config.bld file is given then this parameter is optional, and by default the compiler will be the one configured there. This option can still be used, to override the default established in config.bld.

-p

Name of the RTSC platform package (and optionally instance)

The name of a RTSC platform package to use, using the syntax my.pkg.name or my.pkg.name:instanceName. For example, ti.platforms.sim64Pxx or ti.platforms.generic:custom.

This is an optional parameter, and by default the platform is the one that the selected target names as its default. The user may override this default in their config.bld or by using this parameter.

The optional :instanceName suffix names a pre-configured variant of the platform, which can be set up either in the user's config.bld or in the platform package itself. For more details, see Build.platformTable and the IPlatform interface.

-r

Build profile to use

The name of the build profile to use for the RTSC content, for example 'release' or 'debug'. The list of allowed profiles is determined by the RTSC target module named.

-b

Read build environment from the named config.bld file

A config.bld file can optionally be used to hold the values of the target, compiler root directory, platform, and other more advanced options. This is a convenient way to share a common build environment between multiple projects.

The format of the file is JavaScript statements with the XDCscript extensions. The script should set the properties of the Build global object.

If no config.bld file is given then the target and compiler root directory are required command-line parameters.

--cb

Use a config.bld found along the package path

Find a config.bld by searching the package path, instead of via an explicit pathname. Looks for a file named config.bld in any of the directories named along the package path, in order. The directories are not searched recursively.

-D

Set a Java property in the configuration script

Allows values to be injected from the command line into the config.bld file. For example, the option -Dmyprop=myval creates a property named myprop with string value "myval". This can be read in config.bld using the XDCscript syntax environment["myprop"].

--rtsName

Set the name of the RTSC runtime package

The name of a package containing pre-built libraries containing the xdc.runtime modules. If this parameter is null (or undefined) the name of the rts package is taken from the target (xdc.bld.ITarget.rtsName). If this parameter is set to the empty string (""), then no rts package is included in the configuration. Finally, if this parameter is non-null and non-empty, it should be the name of a package along the package path that can supply pre-built versions of the modules in the xdc.runtime package.

--cfgArgs

Optional arguments passed to configuration script

Lets the user pass values into the configuration script from the command line. The argument is an expression in JavaScript syntax. Its value is available in the configuration script under the name Program.build.cfgArgs.

The JavaScript expression is evaluated in the configuration domain after the platform package is imported, immediately before calling the user's configuration script.

This string has the same effect as the cfgArgs string in xdc.bld.Executable.Attrs.

You can pass multiple values to configuration scripts using the syntax of a JavaScript Object constant:

      xs xdc.tools.configuro --cfgArgs "{foo:'hello';bar:2}" ... app.cfg

The configuration script can read the various fields as, e.g.:

      if (Program.build.cfgArgs.foo == "hello") {
          :
      }

Note the use of single quotes around the string value 'hello' on the command line. This is the easiest way to quote a JavaScript string constant that is compatible with the enclosing double quotes, which are for the benefit of the command line shell.

--linkTemplate

Linker command file template

If this option is provided it overrides the template supplied by the platform, giving the caller complete control over the generated linker command file.

-v

Show verbose details during build

This option produces the same verbose output as the xdc command with the XDCOPTIONS=v parameter.

-q

Minimize details during build

This option produces the same output as the xdc command with the XDCOPTIONS=qq parameter.

-x

Exclude packages matching regexp from compatibility checking

A JavaScript regular expression that is used to select packages that should be excluded from the set of packages checked during configuration.

-w

Treat package version incompatibilites as warnings

If set to "true", force any incompatibilities detected to be treated as warnings only; otherwise incompatibilities are fatal.

--tcf

Read infile.tcf in addition to infile.cfg

The .tcf file optionally configures DSP/BIOS 5.X . This allows a single program to use both DSP/BIOS 5.X and RTSC-based content.

--bios5

Add the DSP/BIOS 5.X include directory to the compiler options

The directory is located in "include" in package "ti.bios".

--pkg

Create the build model generated output files but do not build

This option creates the output directory and key generated files but does not process the user's configuration script. It is used by internal tooling to snapshot the RTSC build settings implied by the configuro command line parameters.

--generationOnly

Create the configuration generated source files but do not build

This option runs the configuration step but does not compile the generated source files. This option is used by internal tooling to eliminate unnecessary build steps.

--compileOptions

Add compile options for C files in the configuration package

This option accepts one or more compiler options that are added to the compiler command line when compiling C files in the generated configuration package. If multiple compiler options are given, the whole string containing options must be surrounded by quotes.

--oc

Set the name of the compiler options file (default is "compiler.opt")

--ol

Set the name of the linker command file (default is "linker.cmd")

infile.cfg

A user-supplied configuration script that names a set of RTSC modules, and optionally changes their configuration settings.

outdir/

A directory containing all generated build artifacts.

outdir/compiler.opt

A file containing C compiler command-line flags. These flags must included on the compiler command line for any C source file that directly accesses the RTSC content. The flags define the header file include paths, and machine-mode compiler flags to ensure object code compatibility between all included content.

outdir/linker.cmd

A file containing linker command-line flags. These flags must be included on the linker command line for the final link of the application. The flags list needed libraries and object files, and on some platforms define the embedded system memory map.

      xs xdc.tools.configuro myconfig.cfg