ECF Files

Variables

Variables are defined in targets, using the following syntax:

<variable name="..." value="..."/>

The variables visible from a target are the variables specified in that target, recursively in its parent targets, and environment variables. Variables specified in a target override environment variables with the same name. They also override variables with the same name specified in its parent targets.

Variables in pathnames

Variables appearing in pathnames are replaced by the corresponding value if there is a variable with that name visible from the target where the pathname has been specified. It is replaced by an empty string otherwise. Note that variables visible from the project target (if different from the target where the pathname is specified) are not taken into account. Also, variables specified in a child of the target where the pathname is specified are not take into account, even if that pathname is used as part of this child target through inheritance. For example:

<target name="parent">
	<variable name="foo" value="gobo"/>
	<cluster name="foo" location="${foo}/library"/>
</target>
<target name="child" extends="parent">
	<variable name="foo" value="ise"/>
</target>

even when dealing with the target 'child', the pathname of the cluster 'foo' will be expanded to 'gobo/library' and not 'ise/library'.

Nested variables

Variables appearing in the value of other variables:

<variable name="foo" value="gobo"/>
<variable name="bar" value="${foo} is great"/>

are not expanded. So the value of the variable 'bar' is '${foo} is great', and not 'gobo is great'.

Variables in conditions

Contrary to variables appearing in pathnames, variables used in 'custom' clauses of conditions, such as 'foo' in the example below:

<condition/>
	<custom name="foo" value="gobo"/>
</condition/>

only take into account values visible from the project target, and not from the target where this condition has been specified (if different from the project target). So here this condition will be satisfied if the variable 'foo' has the value 'gobo' when viewed from the project target, even if this variable has another value in the current target.

Class mappings

Class mappings are defined in targets and clusters, using the following syntax:

<mapping old_name="..." new_name="..."/>

They are used to create class name aliases. For example if 'old_name' is 'STRING' and 'new_name' is 'STRING_8', it means that whenever the type 'STRING' will be found in the class texts of the given target or cluster, they will be seen as if 'STRING_8' had been typed.

Class mappings specified in a target override mappings with the same 'old_name' specified in its parent targets. Likewise, class mappings specified in clusters override mappings with the same 'old_name' in the enclosing target.

If the class name 'A1' is mapped to class 'B1' in a given library L1, and class 'B1' has been declared in this library, then both 'A1' and 'B1' will be visible in other libraries or systems using this library L1. It is also possible to map the class name 'A1' to a class 'B2' in a given library L1 even though class 'B2' has been declared in another library L2 used by L1. In that case 'A1' will not be visible in other libraries or systems using this library L1. These other libraries or systems will also have to use L2 directly and they will have to contain the same mapping declaration from 'A1' to 'B2.

In case of a class mapping appearing in a cluster C1, the class mapping will be seen in the other clusters of the enclosing target only if the 'new_name' is a class declared in the same cluster C1 (and this name is not overriden by a mapping in the other clusters). Otherwise the class mapping is only seen in the class texts of the given cluster C1.

Note that gec and gelint do not support class mappings at the cluster level, only at the target level.