metaonly module xdc.bld.Executable

Model of a file that can be loaded and executed on a platform

Executable instances represent executable files. Instances must be created via the xdc.bld.PackageContents.addExecutable() function; this ensures that each executable created appears in the package's manifest and that it properly "inherits" appropriate default attributes from the containing package.
XDCscript usage meta-domain sourced in xdc/bld/Executable.xdc
var Executable = xdc.useModule('xdc.bld.Executable');
module-wide constants & types
        obj.profile// target options profile = String  ...
        obj.aopts// asm options for objs added to this exe = String  ...
        obj.copts// C/C++ options for objs added to this exe = String  ...
        obj.cfgcopts// C/C++ options for the C config file = String  ...
        obj.defs// definitions for objs added to this exe = String  ...
        obj.incs// include opts for objs added to this exe = String  ...
        obj.lopts// linker options for this exe = String  ...
        obj.tcopts// tconf options for this exe = String  ...
        obj.xsopts// xs options for this exe = String  ...
        obj.cpuId// optional id of CPU on platform = String  ...
        obj.rtsName// optional run time support package name = String  ...
        obj.cpuArgs// optional register settings = Any  ...
        obj.cfgScript// optional name of config script = String  ...
        obj.cfgHome// optional home package of config model = String  ...
        obj.cfgArgs// optional arguments passed to cfgScript = String  ...
        obj.exportExe// export executable's exe file? = Bool  ...
        obj.exportCfg// export executable's config script? = Bool  ...
        obj.exportSrc// if true, export exe sources to releases = Bool  ...
        obj.linkTemplate// linker command file template for this exe = String  ...
        obj.isRom// if true, exe is a ROMable sub-assembly = Bool  ...
per-instance config parameters
    var params = new Executable.Params// Instance config-params object;
        params.name// Base name of the executable = String undefined;
        params.platform// The name of the platform that will run this executable = String undefined;
per-instance functions
 
struct Executable.Attrs

Optional attributes for an Executable instance

XDCscript usage meta-domain
var obj = new Executable.Attrs;
 
    obj.profile = String  ...
    // target options profile
    obj.aopts = String  ...
    // asm options for objs added to this exe
    obj.copts = String  ...
    // C/C++ options for objs added to this exe
    obj.cfgcopts = String  ...
    // C/C++ options for the C config file
    obj.defs = String  ...
    // definitions for objs added to this exe
    obj.incs = String  ...
    // include opts for objs added to this exe
    obj.lopts = String  ...
    // linker options for this exe
    obj.tcopts = String  ...
    // tconf options for this exe
    obj.xsopts = String  ...
    // xs options for this exe
    obj.cpuId = String  ...
    // optional id of CPU on platform
    obj.rtsName = String  ...
    // optional run time support package name
    obj.cpuArgs = Any  ...
    // optional register settings
    obj.cfgScript = String  ...
    // optional name of config script
    obj.cfgHome = String  ...
    // optional home package of config model
    obj.cfgArgs = String  ...
    // optional arguments passed to cfgScript
    obj.cfgArgsEncoded = Bool  ...
    // if true, cfgArgs is encoded via escape()
    obj.exportExe = Bool  ...
    // export executable's exe file?
    obj.exportCfg = Bool  ...
    // export executable's config script?
    obj.exportSrc = Bool  ...
    // if true, export exe sources to releases
    obj.releases = Release.Instance[]  ...
    // releases that this exe is a part of
    obj.test = Test.Attrs  ...
    // test attrs for tests added to this exe
    obj.linkTemplate = String  ...
    // linker command file template for this exe
    obj.isRom = Bool  ...
    // if true, exe is a ROMable sub-assembly
FIELDS
cfgArgs — This string may contain any expression that can be assigned to a JavaScript property. It is evaluated in the configuration domain after the platform package is imported and just prior to running the executable's configuration script. Its value (after evaluation) is assigned to Program.build.cfgArgs; so, program configuration scripts can use this property to adjust their behavior based on values specified in a build script.
For example, a package's build script might build an executable for each possible level of a "trace" value:
              for (t = 0; t < NUM_TRACE_LEVELS; t++) {
                      :
                  Pkg.addExecutable("myExe" + t, targ, plat, {
                      cfgArgs:   "{traceLevel: " + t + "}",
                      cfgScript: "myExe.cfg"
                  });
              }
In this case, the configuration script myExe.cfg can reference the "trace level" set in the build script by referencing the Program.build.cfgArgs object directly:
              if (Program.build.cfgArgs.traceLevel == 1) {
                  :
              }
cfgArgsEncoded — This boolean flag indicates whether the string cfgArgs should be treated as an encoded string (via ECMA-262 escape()) or not. If this field is true, the string is treated as an encoded string and is decoded via unescape() prior to interpretation.
incs — This string contains include path options used by the compiler (or assembler) to locate include files; e.g., "-I ../../include -I ../c55xx". Note that the syntax of this string may be target dependent.
defs — This string contains options used by the compiler (or assembler) to define macros; e.g., "-D_C6xxx -DDEBUG=1". Note that the syntax of this string may be target dependent.
aopts — This string contains options used by the assembler to produce object files; e.g., "-mP1". Note that the syntax of this string may be target dependent.
copts — This string contains options used by the C/C++ compiler to produce object files; e.g., "-o3 -mi1". Note that the syntax of this string may be target dependent.
cfgcopts — This string contains options used by the C/C++ compiler to compile the generated C config file. If cfgopts is not specified, either explicitly or through Pkg.attrs.cfgcopts, the options specified in copts are used instead.
lopts — This string contains options used by the linker produce object files; e.g., "-l mylib.lib". Note that the syntax of this string may be target dependent.
tcopts — This string contains options passed to tconf. Deprecated, use xsopts instead.
xsopts — This string contains options passed to xs when running configuration scripts; e.g., to turn on the reporting of warnings this string can be set to "-js -w", or to define the name-value pair "FOO=bar" available via the environment hash-table xsopts should be set to "-DFOO=bar".
cfgHome — This string names the package that is bound to the Configuration Model's $homepkg. This home package is automatically loaded as part of configuration and, as a result, may contribute libraries to the configuration.
If this parameter is not specified, the package containing the configuration script is used as the home package. This ensures that the results of a configuration script are independent of the package building the configuration. In most cases, the build package is the package containing the configuration script and this distinction is not important. But there are times when it is important to control the home package; e.g., when an external tool generates a configuration script from information supplied by another package or when a configuration script in not in any package.
cfgScript — This string names the program configuration script used to create the files necessary to create the executable. If cfgScript is not specified, the configuration script is assumed to be <name>.cfg, where <name> is the base name of the executable. If cfgScript is set to null, the executable is assumed to be a "legacy" application that defines main() directly and does not require any xdc.runtime support.
If this string is set to a non-null value, and does not have an extension, then the extension ".cfg" is automatically added.
If the specified configuration file does not exist in the package where the executable is being built and the name does not begin with "./", it is searched for along the package path. Thus, it is possible to use configuration scripts in other packages to build executables; e.g., to use the configuration script "myExe.cfg" from a ti.bios.examples.hello package, cfgScript should be set to "ti/bios/examples/hello/myExe.cfg".
The package containing the specified configuration script is imported prior to running the configuration script and this package is used to set xdc.$homepkg; thus, configuration scripts that use xdc.$homepkg will configure the same executable independent of the package building the executable.
profile — This string names a profile defined by the executable's target. The profile specifies a set of compiler, linker, and archiver options that are to be used when producing the executable. Note that these tool options are in addition to any options specified via aopts, copts, etc.
If this field is not set or set to null, the value of xdc.bld.PackageContents.attrs.profile is used. If xdc.bld.PackageContents.attrs.profile is not specified or equal to null, the "release" profile is used.
cpuId — This string is used to uniquely identify the particular CPU on a platform that will run the executable; on platforms that contain a single CPU, this string is ignored.
rtsName — This string names a RunTime Support (RTS) package that will be implicitly loaded prior to running the executable's configuration script. If this field is set to null, then no RTS package will be loaded. If this field is not set (or set to undefined), the RTS package specified by this executable's target will be used (see xdc.bld.ITarget.rts) .
cpuArgs — This field is a hash-table of name-value pairs interpreted by the CPU as register settings that exist at the time that the executable is loaded; e.g., it is possible to specify a non-reset value for the PMST register on a C54xx CPU by setting this parameter to {PMST: 0xffff}.
exportCfg — If this field is set to true, the configuration script will be part of the releases named in the releases array. If it is unspecified (or set to null) and the release specifies that configurations are to be exported, the configuration script will be part of the release. In all other cases, the configuration is not part of the release.
exportSrc — If this field is set to true, the sources specified via xdc.bld.Executable.addObjects() will be part of the releases named in the releases array. If it is unspecified (or set to null) and the release specifies that sources are to be exported, the sources will be part of the release. In all other cases, the sources are not added to the release.
exportExe — If this field is set to true, the executable will be part of the releases named in the releases array. If it is unspecified (or set to null) and the release specifies that configurations are to be exported, the executable will be part of the release. In all other cases, the executable is not part of the release.
releases — This array contains releases that will contain the executable. Thus, a single executable can be part of any set of releases. Each executable is always added to the package's "default release" in addition to any releases specified in the releases array.
test — If this field is set, it defines default attributes for tests added to this executable, including the implicitly added test (see xdc.bld.PackageContents.addExecutable).
linkTemplate — If this field is set, it defines the linker command file template to be used to link this executable. This specification may, however, be overridden by the configuration script (see xdc.cfg.Program.linkTemplate).
As with configuration scripts, if the specified file does not exist in the package where the executable is being built and the name does not begin with "./", it is searched for along the package path. Thus, it is possible to use templates in other packages to build executables; e.g., to use the linker command file "myExe.cmd" from the ti.bios.examples.hello package, linkTemplate should be set to "ti/bios/examples/hello/myExe.cmd".
DETAILS
Unspecified attributes are "inherited" from xdc.bld.PackageContents.attrs; i.e., if one of fields in this structure is unspecified *and* this field's name matches a field name in xdc.bld.PackageContents.attrs, then this field's value defaults to the value in specified by xdc.bld.PackageContents.attrs. This mechanism makes it possible to establish package-wide default values for any of the "inherited" attributes.
Suppose, for example, that you want all executable files in this package to be built with the 'release' profile, but one particular file must be built with 'debug' (because it is a source example). The following build script fragment shows how this can be accomplished:
      Pkg.attrs.profile = 'release';
      var exe = Pkg.addExecutable('example', ..., {profile: 'debug'});
SEE
Instance Config Parameters

XDCscript usage meta-domain
var params = new Executable.Params;
// Instance config-params object
    params.attrs = Executable.Attrs undefined;
    // This executable's optional attributes
    params.name = String undefined;
    // Base name of the executable
    params.platform = String undefined;
    // The name of the platform that will run this executable
    params.target = ITarget.Module undefined;
    // The target (on a platform) that executable should be built for
config Executable.attrs  // instance

This executable's optional attributes

XDCscript usage meta-domain
var params = new Executable.Params;
  ...
params.attrs = Executable.Attrs undefined;
DETAILS
These attributes are "inherited" by all objects added to this executable; i.e., any object attribute that is undefined but is defined here will be assigned the value from these attributes.
Similarly, any unspecified attributes that also appear in xdc.bld.PackageContents.Attrs are inherited from xdc.bld.PackageContents.attrs.
SEE
config Executable.name  // instance

Base name of the executable

XDCscript usage meta-domain
var params = new Executable.Params;
  ...
params.name = String undefined;
DETAILS
This name is used to construct the final executable file name as follows:
      <name>.x<target_suffix>
where <name> is name and <target_suffix> is the suffix defined by each target that the file is built for. See NOTE in xdc.bld for filename rules.
Note: if the same executable is to be built for different platforms (having the same target), then name must "encode" the platform's name.
config Executable.platform  // instance

The name of the platform that will run this executable

XDCscript usage meta-domain
var params = new Executable.Params;
  ...
params.platform = String undefined;
DETAILS
Platforms are modeled as packages that have a module called "Platform"; thus the platform name is really a package name.
config Executable.target  // instance

The target (on a platform) that executable should be built for

XDCscript usage meta-domain
var params = new Executable.Params;
  ...
params.target = ITarget.Module undefined;
DETAILS
This parameter is used to determine the target to use for any objects added to the executable.
During configuration, the executable's platform package can validate that the target is compatible with the configuration of the platform; the target object is accessible via the expression Program.build.target.
Executable.addObjects()  // instance

Add specified object to be built and linked into this executable

XDCscript usage meta-domain
inst.addObjects(String[] names, Object.Attrs objAttrs) returns Void
ARGUMENTS
names — array of base names of the sources of object files to be created and linked into the executable. See NOTE in xdc.bld for filename rules.
objAttrs — optional xdc.bld.Object.Attrs for the array of objects added; all objects named by names will be given the attributes objAttrs.
DETAILS
All objects added to the executable are built with the symbol xdc_cfg__header__ defined to be the name of the executable-specific C header generated by the program configuration tool. This symbol is used by the xdc/cfg/global.h header to include the generated header file; see xdc.cfg.Program.global. Thus, it is possible to portably include configuration specific definitions in a source file that is used in many different configurations.
For example, a portable main.c might be structured as follows:
      #include <xdc/std.h>
      #include <ti/bios/include/log.h>

      #include <xdc/cfg/global.h>    // include declaration of trace
      
      int main(int argc, char *argv[])
      {
          LOG_printf(trace, "hello world");
              :
      }
EXAMPLES
1. Locate a source file whose name starts with "hello" with an extension supported by the executable's target, compile it and link it into the executable myExe:
          myExe.addObjects(["hello"]);
If hello.c exists, compile and add to myExe, if hello.asm exists assemble and add to myExe, etc. If no such file is located, a warning is emitted.
2. Compile hello.c and add to the executable myExe:
          myExe.addObjects(["hello.c"]);
3. Names may include sub-directory prefixes. In this case, the source will be located in a sub-directory of the current package. The following statement declares that the file "foo/hello.c" should be compiled and linked into the executable myExe:
          myExe.addObjects(["foo/hello.c"]);
As in the previous examples, the extension ".c" is optional. In case an extension is not supplied, each extension understood by the target will be tried until a source file is located.
4. It is also possible to supply file specific compilation options.
          myExe.addObjects(["fir.c", "iir.c"], {defs: "-D_DEBUG"});
In this case, both files fir.c and iir.c will be compiled with the "-D_DEBUG" flag. Any setting of attrs.defs in the executable or package is overridden by this definition.
RETURNS
void
THROWS
Error exceptions are thrown for fatal errors
SEE
Executable.addTest()  // instance

Add specified test to executable

XDCscript usage meta-domain
inst.addTest(Test.Attrs testAttrs) returns Test.Instance
ARGUMENTS
testAttrs — test attrs object (xdc.bld.Test.Attrs)
DETAILS
A test encapsulates an executable and a set of arguments passed to the executable when it is run.
Tests are run by naming the goal "<test_name>.test" on the xdc command line; <test_name> is the test's name.
Multiple tests may have the same name; in this case, it is possible to run all tests using the single goal "<test_name>.test"
RETURNS
the xdc.bld.Test instance object created
THROWS
Error exceptions are thrown for fatal errors
generated on Tue, 24 Aug 2010 15:39:30 GMT