TC properties need not have static values only. Since they are defined using JavaScript you can use any JavaScript expression to define the value of a property. But even without using JavaScript, properties can become dynamic by referencing variables.
Another way to make a TC dynamic, is to let a script change it on the fly when it is built. Read more about this in Build Variants.
As already mentioned above there are several variables that can be used in the values of TC properties. Most of these variables are defined in makefiles and the best way to learn about them is to look in the generated makefile and the makefiles that it includes. For example, many variables are defined in the file
However, there are also a few other special variables that can be used in a TC, and that will be expanded during the build of the TC. The table below lists those variables:
| Variables | Descriptions |
|---|---|
| $(TOP_CAPSULE) | This variable can be used in the "Executable name" property of a C++ Executable TC. It expands to the name of the top capsule that is specified by the TC. |
| $(TCONFIG_NAME) | This variable expands to the name of the TC that owns the property where the variable is used. Use this variable in TC properties where you otherwise would hard-code the name of the TC, for example in the "Workspace output path" property. |
| $(CAPSULE_CLASS) | This variable expands to the name of a class generated from a capsule, and can be used in the "Capsule factory" property. For example, you can use it for passing the capsule class as a template parameter to the specified capsule factory, so that the capsule factory can create an instance of the capsule class using the new operator. |
| $(workspace_loc) | This is a standard Eclipse variable which expands to the location of the Eclipse workspace. It can be used in the "Workspace output path" property. It is also available as a make file variable and can therefore be used in all properties which appear in the generated make file (e.g. "Inclusion paths"). |
It is possible to define your own variables and use them within a TC. This can be useful in order to create more generic TCs which can be used in different environments. Rather than changing the TC in each environment, or using different TCs for different environments, the user-defined variables can be changed instead in order to accomplish the build variations that are necessary in a particular environment.
User-defined variables can be defined in different contexts. When a user-defined variable is used in a TC these contexts are scanned in a fixed order to locate a value for the variable. The following contexts are available (listed in the order in which they are scanned):
Path variables defined in the workspace preferences at General – Workspace - Linked Resources
String substitution variables defined in the workspace preferences Run/Debug – String Substitution
Environment variables defined in the system
Most variables do not need to be resolved until the TC is built by the model compiler. If a referenced variable is not defined in any of the three contexts listed above, the model compiler will print a warning. The build will still proceed, but may fail later since the variable could not be resolved. It is therefore strongly recommended to pay attention and fix such warnings. Here is an example of what the warning will look like:
WARNING : Cannot resolve variable '$(TARGET\_LOC)' in 'Location' property:'$(TARGET\_LOC)'
Note that path variables always must specify an absolute path, and can therefore only be used in TC properties that specify paths. Here is the list of TC properties where user-defined variables can be used:
The "Location" property in the Main tab. For example, a location specified as C:/users/USER can be used to let the location of the target project be dependent on a USER variable which each user of the TC can set-up differently (in this case either as a string substitution variable or environment variable). If the location instead would be specified as "$(TARGET_LOC)" then a path variable could be used instead, since the variable then can be resolved with an absolute path.
The "Target services library" property in the Target Configuration tab. Note that this variable is resolved already by the TC editor in order to populate the list of TargetRTS configurations.
The "Build folder" property in the Target Configuration tab for a ”C++ External Library” TC.
The "Build command" property in the Target Configuration tab for a ”C++ External Library” TC.
The "Clean command" property in the Target Configuration tab for a ”C++ External Library” TC.
The ”Constants” property in the Target Configuration tab for a ”C++ External Library” TC. Here path variables are not applicable since the variables specify the values of constants to be used during the build. See External Constants for more information.
The most dynamic way to specify the value of a TC property is to use a JavaScript expression. Such expressions can reference variables defined in JavaScript, contain calls to JavaScript functions and in general use all other features of the JavaScript language. JavaScript expressions are evaluated using Eclipse Nashorn. This in turn means that they can contain calls to Java APIs. For example, here is an example of how to define a TC property by dynamically reading the value of an environment variable using a Java API:
tc.inclusionPaths = \[
java.lang.System.getenv("INCLUDES");
\];
To make it easier to work with dynamic TCs, the TC editor provides a feature for evaluating all properties of a TC and view them in a read-only TC editor. The command to use is called “Open evaluated version” and is available in the TC editor toolbar menu.