EiffelStudio: an EiffelSoftware project - User contributions [en]

EiffelStudio Wish List

2006-11-30T11:25:19Z

Paco: /* General */

[[Category:User suggestions]]
Welcome to the Eiffel/EiffelStudio Wish List. This is the place where you, the community, get a chance to tell us what you think is important to include in the future versions of the Eiffel compiler and EiffelStudio IDE.

Please use this list responsibly and try to correctly categorize your wishes. A brief description may help us evaluate your requirements but please be brief.

Our stock pile of genie snared, dusty gold lamps is running low for our next release ([[EiffelStudio Releases]]) but we'll be sure to scour the lands for more.

== Compiler ==

=== General ===
* A way to author Enum-like class for typed options or flags. Currently using INTEGER and a bag of analogous constants doesn't make Eiffel "elegant".
* Addition of a decimal type / REAL_128 for 28 digit precision - ALREADY EXISTS - class MA_DECIMAL in the Gobo libraries is shipped with the compiler.
* CHARACTER_16 type - Please NO! CHARACTER_32 covers this already.
* 7-bit (US) ASCII_CHARACTER and ASCII_STRING which extends upon an ARRAY [ASCII_CHARACTER] with values of 0-127, removing the need for UTF8 conversion/checking when passing basic char values to C (gtk interfacing for example when connecting to signals)
* Make MUTEX recursive on non-windows platforms or at least provide a mutex and separate recursive mutex for all platforms.
* Ability for multiple precompiles in a system.
* Ability to compile/debug for both 32/64 bit systems via project settings
* Ability for for a fully optimal finalization for systems marked as 'client only', so that unused variables will not get generated in the finalized C Code.
* Ability for studio to work with binutils for cross compilation
* Ability to be able to control all user settable options in studio without having to resort to manually editing files, this is mainly for C compilation options
* Have a smarter C code generation system that can launch a C compilation of any module as soon as the C code is generated, this way we can also be smarter when monitoring C compilation progress
* Ability for ANY to generate a unique id for each object for referencing and hashability
* With hashable ability of ANY, change object graph traversal for serialization so that multiple threads can serialize at the same time without having to wait linearly (lock_marking/unlock_marking)
* Ability for Studio to work and compile with Cygwin
* Ability to get a list of file dependencies in the form of a file listing to stdout. This list would contain a) all .e files used in the system, b) all .lib/.so files explicitly listed in the ECF/Ace file and c) all .h files referenced in external features (ideally that have not been subjected to dead code removal). Preferably, this feature should be able to be used without performing a full compilation (level 4?).

=== .NET ===
* Consume .NET generics. Not being able to use them is becoming harder.<br/>We cannot write Atlas (AJAX) based web applications because of it. The Visual Studio SDK, used by EiffelEnvision, is increasing it's use of generics and preventing use from supporting some features. The people who want to use the .NET framework classes instead of the Eiffel ones cannot use generics and have to resort to using the non-generic versions of list, which bulks implementation and leads ambiguity.
* Emit .NET generics types for Eiffel generic classes.
* Allow direct access to member of TYPED_POINTER [xxx] item out/ref routine arguments.
* Allow direct setting of TYPED_POINTER [xxx] item for out/ref routine arguments.
* Optimized ''call.do_nothing'' as a IL pop instruction to removed returned value.

== IDE ==
* Give the user control over which classes will be compiled over the GUI (say: click on grey class and it becomes yellow and will be compiled always from now on, even though it may not be used at all. This is good for development of classes which are not added over GUI in ES.)
* While searching for word or after a double click on a word, it would be nice if all words would be highlighted in pastel color style.
* It's a pain to pick`n`drop huge features source code into the context window for setting break point. What about the following: Pick on the right side of the class text picks the feature as well? (Pick on the left side of the class text picks already the feature call).
* Make editor and grid more theme compliant in terms of color and font
* Remove all use of EV_TREE and EV_MULTI_COLUMN_LIST from studio so that all list widgets are drawn by vision2, this will make porting easier, we can also use the grid items to be able to change names of clusters, classes and features inline via the tree items.
* Extended static checking integrated into the IDE.
* Rearrange widgets of ''search tool'' so that they use free space on the right. Currently it uses too much vertical space.

== Other ==
* Provide a WEAK_REFERENCE [G] class to abstract away the implementation details currently provided by IDENTIFIED for implementing weak references.
* Locale support to determine what the default charset is (or whether it is UTF-8 or not)
* Build an object storing database with built-in record locking so that multiple systems can have access to the same 'objects'
* Make base.ecf rely on smaller ecf's (kernel.ecf, structures.ecf, support.ecf) so that these smaller dependancies can be compiled in only if needs be. It would be good if ANY could be optimized so that it doesn't have any references to io (or print) or mismatch information (only needed when storable is employed) as these bring in a lot of overhead when compiling a simple system. The smaller ecf could also link in with the object files of the runtime to avoid linking against a monolithic runtime (cecil, storable, etc) when you only want to print ("Hello World")
* Put more of the run-time code in to inline C code reducing the size of the executable if you are not using certain features, ideally the linked against runtime should only contain the core functionality needed to create objects, perform simple operations and garbage collect, any other features can be brought in on a class/library/configuration level.

User:Paco

2006-09-17T11:37:10Z

Paco:

[[Category:People]]

==About me==
Software developer. Computer Science enginering degree from LTH, Lund, Sweden 1993. Consultant for Generic Integration AB, Stockholm, Sweden.

==Current work projects==
* Vaktis. A RBAC-system written in Eiffel.
* ELDAP. Eiffel LDAP library.
* aPig. API generator. Generates Eiffel classes, C header files, DEF files, SWIG .i files and HTML documentation from aPig specification files.
* Eiffel Studio builder for SCons.

==Current spare time projects==
* ECLOP. Eiffel command line parser library.
* Yeps (Yet another Eiffel Persistence solution). Berkeley DB based Eiffel persistance library.
* Taxosoft. System for working with biological taxonomies and nomenclature

User:Paco

2006-09-17T11:36:17Z

Paco:

[[Category:People]]

==About me==
Software developer. Computer Science enginering degree from LTH, Lund, Sweden 1993. Consultant for Generic Integration AB, Stockholm, Sweden.

==Current work projects==
*[[Vaktis. A RBAC-system written in Eiffel.]]
*[[ELDAP. Eiffel LDAP library.]]
*[[aPig. API generator. Generates Eiffel classes, C header files, DEF files, SWIG .i files and HTML documentation from aPig specification files.]]
*[[Eiffel Studio builder for SCons.]]

==Current spare time projects==
*[[ECLOP. Eiffel command line parser library.]]
*[[Yeps (Yet another Eiffel Persistence solution). Berkeley DB based Eiffel persistance library.]]
*[[Taxosoft. System for working with biological taxonomies and nomenclature]]

Talk:ProposalConfigurationDiscovery

2006-09-17T08:08:50Z

Paco:

'''--[[User:Patrickr|Patrickr]] 02:53, 14 September 2006 (CEST)'''

Maybe we could think of libraries more like "plugins" for eiffelstudio (and maybe at a later point there could even be plugins).
I could imagine a dialog where I could select the libraries to download (and this would also handle dependencies).

Points to think about I see are: dependency handling, nameing schema (for dependency handling), version handling (problems like library a needs version < 2 of b and library c needs version > 2 of b)

In general it may make sense to have a look at how others have solved this problems (e.g. plugin system in eclipse, apt system in debian, ...)

'''--[[User:Paco|Paco]] 10:08, 17 September 2006 (CEST)'''

I would very much like to see an application that is independent of Eiffel
Studio that could handle installation of Eiffel libraries and components, and
also depenedencies between libraries and components. I think that looking at
other "package" handlers like APT is a very good start. Maybe apt could be used
"as is" but with little tweaks.

It is important that the application is independent of Eiffel Studio in the
sense that it can be upgraded independently of Eiffel Studio. In general it
would be good if the application is independent of Eiffel Studio, but at the
same time that it can easily be started/called from within Eiffel Studio.

Some general requirements are:

* Ability to have multiple versions of a given library/component installed. This is useful both for people who are working in different projects using different library/component versions and when upgrading from one library/component version to another.

* Eiffel Studio itself should be regarded as any other library/component as regards dependencies. Eg: "requires EiffelStudio 5.7|6.0".

* A reference implementation of the application should be done as a command line program so that it is scriptable.

* It would be very nice if the application also could handle CVS/Subversion checkouts/updates for a given library/component (relying of course on the standard CVS/Subversion command line tools).

A requirement on ace/ecf files is that it must be easy to switch between different versions of a given library/component. Ace/ecf files should also explicitly list which version of each library/component the system should be compiled against.

Talk:ProposalConfigurationDiscovery

2006-09-17T08:00:56Z

Paco:

Talk:ProposalConfigurationDiscovery

2006-09-17T07:58:35Z

Paco:

'''--[[User:Patrickr|Patrickr]] 02:53, 14 September 2006 (CEST)'''

Maybe we could think of libraries more like "plugins" for eiffelstudio (and maybe at a later point there could even be plugins).
I could imagine a dialog where I could select the libraries to download (and this would also handle dependencies).

Points to think about I see are: dependency handling, nameing schema (for dependency handling), version handling (problems like library a needs version < 2 of b and library c needs version > 2 of b)

In general it may make sense to have a look at how others have solved this problems (e.g. plugin system in eclipse, apt system in debian, ...)

I would very much like to see an application that is independent of Eiffel Studio that could handle installation of Eiffel libraries and components, and also depenedencies between libraries and components. I think that looking at other "package" handlers like APT is a very good start. Maybe apt could be used "as is" but with little tweaks.

It is important that the application is independent of Eiffel Studio in the sense that it can be upgraded independently of Eiffel Studio. In general it would be good if the application is independent of Eiffel Studio, but at the same time that it can easily be started/called from within Eiffel Studio.

Some general requirements are:

* Ability to have multiple versions of a given library/component installed. This is useful both for people who are working in different projects using different library/component versions and when upgrading from one library/component version to another.

* Eiffel Studio itself should be regarded as any other library/component as regards dependencies. Eg: "requires EiffelStudio 5.7|6.0".

* A reference implementation of the application should be done as a command line program so that it is scriptable.

* It would be very nice if the application also could handle CVS/Subversion checkouts/updates for a given library/component (relying of course on the standard CVS/Subversion command line tools).

A requirement on ace/ecf files is that it must be easy to switch between different versions of a given library/component. Ace/ecf files should also explicitly list which version of each library/component the system should be compiled against.

Configuration

2006-07-01T21:51:03Z

Paco: /* General ideas */

[[Category:EiffelStudio]]
[[Category:Compiler]]
[[Category:Configuration]]
== General ideas ==
* as much as possible independant from the system (windows/unix)
* one file with multiple configurations (eg. debug, release build)
* include/exclude as regexp pattern
* global ignore patterns (eg. cvs/svn)
* include other configuration files (eg. to add a library just include the config file of the library)
* relative paths
* actions before/after run/compile (eg. start a server)

=== Things to implement ideas ===
* conditions (if windows then ... elseif unix then ... end)
* variables (user and predefined)
* inheritance of configuration
* C code to compile (when wrapping C API:s or optimizing code)
* Flags to C compiler and linker

=== Other ===
* convert old ace files into new format
* *.epr vs *.ace
* [[ProjectFiles]]

== Possible implementation layout ==

Some more information are available here: http://www.ise/tools/public_zone/index.php?op=dl&path=/home/patrickr/public_html/Public/project_configuration.pdf (Part with two config files has changed to only one config file.)

[[Image:Configuration1.jpg]]

A system consists of multiple targets. A target can extend another target. A target can have some libraries, assemblies, clusters and override clusters.
A library has an associated target. A cluster can have a parent cluster. An override cluster has a some groups it overrides.

<code>[eiffel, N]
indexing
description: "The configuration system."
date: "$Date$"
revision: "$Revision$"

class
CONF_SYSTEM

feature

name: STRING
-- Name of the system.

uuid: STRING
-- UUID of this system. Used to uniquely identify libraries.

targets: LIST [CONF_TARGET]
-- The configuration targets.

library_target: CONF_TARGET
-- The target to use if this is used as a library.

compileable_targets: LIST [CONF_TARGET]
-- Targets that can be compiled (e.g. have a root feature).
end
</code>

<code>[eiffel, N]
indexing
description: "A configuration target."
date: "$Date$"
revision: "$Revision$"

class
CONF_TARGET

feature

name: STRING
-- Name of the target.

version: CONF_VERSION
-- Version number of the target.

extends: CONF_TARGET
-- If we extend another target, this is the other target.

libraries: LIST [CONF_LIBRARY]
-- The used libraries.

overrides: LIST [CONF_OVERRIDE]
-- The override clusters.

clusters: LIST [CONF_CLUSTER]
-- The normal clusters.

assemblies: LIST [CONF_ASSEMBLY]
-- The assemblies.

root: CONF_ROOT
-- The root feature.

options: CONF_OPTIONS
-- The options (assertions, debugs, warnings, ...)

file_rule: CONF_FILE_RULE
-- Globally exclude/include file rules.

external_include: LIST [CONF_EXTERNAL_INCLUDE]
-- Global external include files.

external_objec: LIST [CONF_EXTERNAL_OBJECT]
-- Global external object files.

external_ressource: LIST [CONF_EXTERNAL_RESSOURCE]
-- Global external ressource files.

pre_compile: LIST [CONF_ACTION]
-- Actions to be executed before compilation.

post_action: LIST [CONF_ACTION]
-- Actions to be executed after compilation.

variables: LIST [CONF_VARIABLE]
-- User defined variables.
end
</code>

<code>[eiffel, N]
indexing
description: "Base class for configuration groups."
date: "$Date$"
revision: "$Revision$"

class
CONF_GROUP

inherit
CONF_CONDITIONED

feature

name: STRING
-- The name of the group.

directory: CONF_DIRECTORY
-- The directory of the group.

options: CONF_OPTIONS
-- The options (assertions, debugs, warnings, ...)

name_prefix: STRING
-- An optional name prefix for this group.

renaming: HASH_TABLE [STRING, STRING]
-- Mapping of renamed classes from the old name to the new name.

class_options: HASH_TABLE [CONF_OPTION, STRING
-- Classes with specific options.

end
</code>

<code>[eiffel, N]
indexing
description: "A library."
date: "$Date$"
revision: "$Revision$"

class
CONF_LIBRARY

inherit
CONF_GROUP

feature

library_target: CONF_TARGET
-- The library target.

end
</code>

<code>[eiffel, N]
indexing
description: "A project cluster."
date: "$Date$"
revision: "$Revision$"

class
CONF_CLUSTER

inherit
CONF_GROUP

feature
is_recursive: BOOLEAN
-- Are subdirectories included recursively?

parent: CONF_CLUSTER
-- An optional parent cluster.

dependencies: LIST [CONF_GROUP]
-- Dependencies to other groups.

file_rule: CONF_FILE_RULE
-- Globally exclude/include file rules.

is_visible (a_feature, a_class: STRING): BOOLEAN
-- Is a feature of this cluster visible?
end
</code>
<code>[eiffel, N]
indexing
description: "Clusters that override other groups."
date: "$Date$"
revision: "$Revision$"

class
CONF_OVERRIDE

inherit
CONF_CLUSTER

feature

override: LIST [CONF_GROUP]
-- The groups that this cluster overrides.

end
</code>

CONF_CONDITIONED is a class that allows to specify for which platform, build tuple something is enabled. Conditioned are: CONF_ACTION (pre-/postcompile actions), CONF_EXTERNAL_(INCLUDE|OBJECT|RESSOURCE), CONF_GROUP

== Pseudocode example configuration ==
files/eiffelvision/eiffelvision.ace
<pre>
system EiffelVision

target Library
version 2.0.0.1
uuid 15ac36b5-2c65-41e9-8309-c504dd430a0b

library base
files/base/base.ace

cluster vision
files/vision
recursive
uses base

external_include
files/include/common.h [(all, all)]
files/include/windows.h [(windows, all)]
files/include/gtk [(unix, all)]

external_objects
files/obj/windows.o [(windows, all)]
files/obj/gtk.o [(unix, all)]
files/obj/debug.o [(unix, workbench)]

target Debug extends Library

cluster debug
files/debug
recursive
uses base, vision

root debug:ROOT_CLASS:make

</pre>

files/eiffelstudio/eiffelstudio.ace
<pre>
system EiffelStudio
version 5.0.0.1
uuid 9a8d3871-ef44-484c-9029-c52d17df40f0

target Common

variable gobo_setting="some settings"

exclude
^\.svn$

library base
files/base/base.ace

library gobo
files/gobo/gobo.ace
rename "some_class" as "new_class"
prefix "gobo_"

cluster compiler
files/compiler
uses base, gobo

root compiler:ROOT_CLASS:make

target Console extends Common

cluster console
files/console
uses base, gobo, compiler

cluster mysub (console)
$/mysub

target Workbench extends Common

library eiffelvision
files/eiffelvision/eiffelvision.ace

cluster workbench
files/workbench
uses base, gobo, eiffelvision, compiler
</pre>

== Questions and Problems ==

*Specify use of other clusters? '''Yes'''
*Variables? '''If not defined, take environment variable.'''
*Path relative to ace file? '''Yes'''
*When are two libraries the same? '''UUID: http://www.famkruithof.net/guid-uuid-random.html'''
=== Multiple library usage ===
====Problem====
<pre>
System Application

library A
library B
</pre>
<pre>
System A

library C
option Yes
</pre>
<pre>
System B

library C
option No
</pre>
We have a conflict for the option on library C.

====Solution====
If the library is directly used in Application, use the this options, otherwise use the options of the Application system.

===File pattern===
The file pattern match against the relative path in unix format in a cluster.
e.g. if the cluster is in C:\mycluster

<table border="true">
<tr>
<th>Pattern</th>
<th>Matches</th>
</tr>
<tr>
<td>
storage/table
</td>
<td>
C:\mycluster\storage\table\*
C:\mycluster\storage\table.e
C:\mycluster\something\storage\table\*
</td>
</tr>
<tr>
<td>
^/storage/table/
</td>
<td>
C:\mycluster\storage\table\*
</td>
</tr>
<tr>
<td>
^/.*/test/
</td>
<td>
C:\mycluster\a\test\*
C:\mycluster\b\test\*
</td>
</tr>

<tr>
<td>
/test/
</td>
<td>
C:\mycluster\a\test\*
C:\mycluster\b\test\*
C:\mycluster\something\table\test\*
</td>
</tr>
</table>

== Configuration file format ==
[[ConfigurationFileFormat|Configuration file format page]]

== Migration ==
[[ConfigurationMigration|Configuration migration]]

== Degree 6 ==
[[ConfigurationDegree6|Configuration degree 6]]

== Ideas for better conditions ==
[[ConfigurationConditions|Configuration conditions]]

Configuration

2006-07-01T21:50:14Z

Paco: /* Things to implement ideas */

[[Category:EiffelStudio]]
[[Category:Compiler]]
[[Category:Configuration]]
== General ideas ==
* as much as possible independant from the system (windows/unix)
* one file with multiple configurations (eg. debug, release build)
* include/exclude as regexp pattern
* global ignore patterns (eg. cvs/svn)
* include other configuration files (eg. to add a library just include the config file of the library)
* relative paths
* actions before/after run/compile (eg. start a server)

=== Things to implement ideas ===
* conditions (if windows then ... elseif unix then ... end)
* variables (user and predefined)
* inheritance of configuration
* C code to compile (when wrapping C API:s or optimizing code)

=== Other ===
* convert old ace files into new format
* *.epr vs *.ace
* [[ProjectFiles]]

== Possible implementation layout ==

Some more information are available here: http://www.ise/tools/public_zone/index.php?op=dl&path=/home/patrickr/public_html/Public/project_configuration.pdf (Part with two config files has changed to only one config file.)

[[Image:Configuration1.jpg]]

A system consists of multiple targets. A target can extend another target. A target can have some libraries, assemblies, clusters and override clusters.
A library has an associated target. A cluster can have a parent cluster. An override cluster has a some groups it overrides.

<code>[eiffel, N]
indexing
description: "The configuration system."
date: "$Date$"
revision: "$Revision$"

class
CONF_SYSTEM

feature

name: STRING
-- Name of the system.

uuid: STRING
-- UUID of this system. Used to uniquely identify libraries.

targets: LIST [CONF_TARGET]
-- The configuration targets.

library_target: CONF_TARGET
-- The target to use if this is used as a library.

compileable_targets: LIST [CONF_TARGET]
-- Targets that can be compiled (e.g. have a root feature).
end
</code>

<code>[eiffel, N]
indexing
description: "A configuration target."
date: "$Date$"
revision: "$Revision$"

class
CONF_TARGET

feature

name: STRING
-- Name of the target.

version: CONF_VERSION
-- Version number of the target.

extends: CONF_TARGET
-- If we extend another target, this is the other target.

libraries: LIST [CONF_LIBRARY]
-- The used libraries.

overrides: LIST [CONF_OVERRIDE]
-- The override clusters.

clusters: LIST [CONF_CLUSTER]
-- The normal clusters.

assemblies: LIST [CONF_ASSEMBLY]
-- The assemblies.

root: CONF_ROOT
-- The root feature.

options: CONF_OPTIONS
-- The options (assertions, debugs, warnings, ...)

file_rule: CONF_FILE_RULE
-- Globally exclude/include file rules.

external_include: LIST [CONF_EXTERNAL_INCLUDE]
-- Global external include files.

external_objec: LIST [CONF_EXTERNAL_OBJECT]
-- Global external object files.

external_ressource: LIST [CONF_EXTERNAL_RESSOURCE]
-- Global external ressource files.

pre_compile: LIST [CONF_ACTION]
-- Actions to be executed before compilation.

post_action: LIST [CONF_ACTION]
-- Actions to be executed after compilation.

variables: LIST [CONF_VARIABLE]
-- User defined variables.
end
</code>

<code>[eiffel, N]
indexing
description: "Base class for configuration groups."
date: "$Date$"
revision: "$Revision$"

class
CONF_GROUP

inherit
CONF_CONDITIONED

feature

name: STRING
-- The name of the group.

directory: CONF_DIRECTORY
-- The directory of the group.

options: CONF_OPTIONS
-- The options (assertions, debugs, warnings, ...)

name_prefix: STRING
-- An optional name prefix for this group.

renaming: HASH_TABLE [STRING, STRING]
-- Mapping of renamed classes from the old name to the new name.

class_options: HASH_TABLE [CONF_OPTION, STRING
-- Classes with specific options.

end
</code>

<code>[eiffel, N]
indexing
description: "A library."
date: "$Date$"
revision: "$Revision$"

class
CONF_LIBRARY

inherit
CONF_GROUP

feature

library_target: CONF_TARGET
-- The library target.

end
</code>

<code>[eiffel, N]
indexing
description: "A project cluster."
date: "$Date$"
revision: "$Revision$"

class
CONF_CLUSTER

inherit
CONF_GROUP

feature
is_recursive: BOOLEAN
-- Are subdirectories included recursively?

parent: CONF_CLUSTER
-- An optional parent cluster.

dependencies: LIST [CONF_GROUP]
-- Dependencies to other groups.

file_rule: CONF_FILE_RULE
-- Globally exclude/include file rules.

is_visible (a_feature, a_class: STRING): BOOLEAN
-- Is a feature of this cluster visible?
end
</code>
<code>[eiffel, N]
indexing
description: "Clusters that override other groups."
date: "$Date$"
revision: "$Revision$"

class
CONF_OVERRIDE

inherit
CONF_CLUSTER

feature

override: LIST [CONF_GROUP]
-- The groups that this cluster overrides.

end
</code>

CONF_CONDITIONED is a class that allows to specify for which platform, build tuple something is enabled. Conditioned are: CONF_ACTION (pre-/postcompile actions), CONF_EXTERNAL_(INCLUDE|OBJECT|RESSOURCE), CONF_GROUP

== Pseudocode example configuration ==
files/eiffelvision/eiffelvision.ace
<pre>
system EiffelVision

target Library
version 2.0.0.1
uuid 15ac36b5-2c65-41e9-8309-c504dd430a0b

library base
files/base/base.ace

cluster vision
files/vision
recursive
uses base

external_include
files/include/common.h [(all, all)]
files/include/windows.h [(windows, all)]
files/include/gtk [(unix, all)]

external_objects
files/obj/windows.o [(windows, all)]
files/obj/gtk.o [(unix, all)]
files/obj/debug.o [(unix, workbench)]

target Debug extends Library

cluster debug
files/debug
recursive
uses base, vision

root debug:ROOT_CLASS:make

</pre>

files/eiffelstudio/eiffelstudio.ace
<pre>
system EiffelStudio
version 5.0.0.1
uuid 9a8d3871-ef44-484c-9029-c52d17df40f0

target Common

variable gobo_setting="some settings"

exclude
^\.svn$

library base
files/base/base.ace

library gobo
files/gobo/gobo.ace
rename "some_class" as "new_class"
prefix "gobo_"

cluster compiler
files/compiler
uses base, gobo

root compiler:ROOT_CLASS:make

target Console extends Common

cluster console
files/console
uses base, gobo, compiler

cluster mysub (console)
$/mysub

target Workbench extends Common

library eiffelvision
files/eiffelvision/eiffelvision.ace

cluster workbench
files/workbench
uses base, gobo, eiffelvision, compiler
</pre>

== Questions and Problems ==

*Specify use of other clusters? '''Yes'''
*Variables? '''If not defined, take environment variable.'''
*Path relative to ace file? '''Yes'''
*When are two libraries the same? '''UUID: http://www.famkruithof.net/guid-uuid-random.html'''
=== Multiple library usage ===
====Problem====
<pre>
System Application

library A
library B
</pre>
<pre>
System A

library C
option Yes
</pre>
<pre>
System B

library C
option No
</pre>
We have a conflict for the option on library C.

====Solution====
If the library is directly used in Application, use the this options, otherwise use the options of the Application system.

===File pattern===
The file pattern match against the relative path in unix format in a cluster.
e.g. if the cluster is in C:\mycluster

<table border="true">
<tr>
<th>Pattern</th>
<th>Matches</th>
</tr>
<tr>
<td>
storage/table
</td>
<td>
C:\mycluster\storage\table\*
C:\mycluster\storage\table.e
C:\mycluster\something\storage\table\*
</td>
</tr>
<tr>
<td>
^/storage/table/
</td>
<td>
C:\mycluster\storage\table\*
</td>
</tr>
<tr>
<td>
^/.*/test/
</td>
<td>
C:\mycluster\a\test\*
C:\mycluster\b\test\*
</td>
</tr>

<tr>
<td>
/test/
</td>
<td>
C:\mycluster\a\test\*
C:\mycluster\b\test\*
C:\mycluster\something\table\test\*
</td>
</tr>
</table>

== Configuration file format ==
[[ConfigurationFileFormat|Configuration file format page]]

== Migration ==
[[ConfigurationMigration|Configuration migration]]

== Degree 6 ==
[[ConfigurationDegree6|Configuration degree 6]]

== Ideas for better conditions ==
[[ConfigurationConditions|Configuration conditions]]