<?xml version="1.0"?> 

<!--
	description:

		"ECF Files"

	library: "Gobo Eiffel Tools Library"
	copyright: "Copyright (c) 2008-2020, Eric Bezault and others"
	license: "MIT License"
	date: "$Date$"
	revision: "$Revision$"
-->

<chapter xmlns="http://www.gobosoft.com/eiffel/gobo/documentation" id="tools/ecf">
<chapterinfo>
	<copyright>
		<year>2008-2020</year>
		<holder>Eric Bezault</holder>
	</copyright>
	<author>
		<firstname>Eric</firstname><surname>Bezault</surname>
	</author>
	<email>ericb@gobosoft.com</email>
	<date>6 April 2020</date>
</chapterinfo>

<title>ECF Files</title>

<para>
Under construction
</para>

<section><title>Variables</title>
<para>
Variables are defined in targets, using the following syntax:
<blockquote><programlisting>
&lt;variable name="..." value="..."/&gt;
</programlisting></blockquote>
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.
</para>
<section><title>Variables in pathnames</title>
<para>
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:
<blockquote><programlisting>
&lt;target name="parent"&gt;
	&lt;variable name="foo" value="gobo"/&gt;
	&lt;cluster name="foo" location="${foo}/library"/&gt;
&lt;/target&gt;
&lt;target name="child" extends="parent"&gt;
	&lt;variable name="foo" value="ise"/&gt;
&lt;/target&gt;
</programlisting></blockquote>
even when dealing with the target 'child', the pathname of the cluster 'foo' will be
expanded to 'gobo/library' and not 'ise/library'.
</para>
</section>
<section><title>Nested variables</title>
<para>
Variables appearing in the value of other variables:
<blockquote><programlisting>
&lt;variable name="foo" value="gobo"/&gt;
&lt;variable name="bar" value="${foo} is great"/&gt;
</programlisting></blockquote>
are not expanded. So the value of the variable 'bar' is '${foo} is great', and not 'gobo is great'.
</para>
</section>
<section><title>Variables in conditions</title>
<para>
Contrary to variables appearing in pathnames, variables used in 'custom' clauses of
conditions, such as 'foo' in the example below:
<blockquote><programlisting>
&lt;condition/&gt;
	&lt;custom name="foo" value="gobo"/&gt;
&lt;/condition/&gt;
</programlisting></blockquote>
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.
</para>
</section>
</section>

<section><title>Class mappings</title>
<para>
Class mappings are defined in targets and clusters, using the following syntax:
<blockquote><programlisting>
&lt;mapping old_name="..." new_name="..."/&gt;
</programlisting></blockquote>
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.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
Note that <projectname>gec</projectname> and <projectname>gelint</projectname>
do not support class mappings at the cluster level, only at the target level.
</para>
</section>

</chapter>
