Difference between revisions of "ConfigurationOptions"

 
(9 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
[[Category:Configuration]]
 
[[Category:Configuration]]
 
Handling of options specified in libraries.
 
Handling of options specified in libraries.
 
[[Image:Config example.png]]
 
  
 
== Available Options ==
 
== Available Options ==
Line 17: Line 15:
  
 
== Problem ==
 
== Problem ==
Should option values be specified in a library or in a project that uses the library?
+
Should option values be specified in a library or in a project that uses the library? Below we describe the two possible solutions. The implemented solution is number 1 "Library approach".
  
== Solutions ==
+
== Solution 1: Library approach ==
=== Library ===
+
 
A library is a black box and therefore everything is specified in the library. Usual settings could be
 
A library is a black box and therefore everything is specified in the library. Usual settings could be
 
* read only
 
* read only
Line 28: Line 25:
 
* optimize
 
* optimize
  
==== Overriding values ===
+
==== Overriding values ====
* on libraries directly included in the application we can specify option values directly in the library group that includes the library
+
* on libraries directly included in the application we can specify option values (or alternatively set a flag that specifies to use the application options) directly in the library group that includes the library
  
=== Application ===
+
== Solution 2: Application approach ==
 
An application should have full control, therefore we use values specified in the application. A common scenario could be that a user has a library which he uses in another application and the testing of the library is done by using it in the application, therefore all warnings should be reported, debugs, trace, profile could be enabled, assertion level may be higher.
 
An application should have full control, therefore we use values specified in the application. A common scenario could be that a user has a library which he uses in another application and the testing of the library is done by using it in the application, therefore all warnings should be reported, debugs, trace, profile could be enabled, assertion level may be higher.
 +
 +
== Example for various solutions ==
 +
[[Image:Config example.png]]
 +
 +
Simplified configuration system of the compiler. ES is EiffelStudio (the application), vision2 is the graphic library used by ES which internally uses WEL. The application and all libraries use base.
 +
 +
=== Library approach ===
 +
Base, vision2, wel set the options and those options are used. The options of base and vision2 can be overridden (but they have to be overridden for each library separately), wel can not be overridden (unless it is included in the application directly).
 +
 +
=== Application approach ===
 +
All the options are specified in ES, it's possible to specify specific values for the used libraries that are directly included, otherwise the default values from the application will be taken.

Latest revision as of 11:49, 30 October 2006

Handling of options specified in libraries.

Available Options

  • read only
  • assertions
  • .NET namespace
  • profile
  • trace
  • optimize (unused)
  • .NET application optimize
  • debug clauses
  • warnings

Problem

Should option values be specified in a library or in a project that uses the library? Below we describe the two possible solutions. The implemented solution is number 1 "Library approach".

Solution 1: Library approach

A library is a black box and therefore everything is specified in the library. Usual settings could be

  • read only
  • precondition assertions
  • some useful .NET namespace
  • no profile, no trace, no debug, no warnings
  • optimize

Overriding values

  • on libraries directly included in the application we can specify option values (or alternatively set a flag that specifies to use the application options) directly in the library group that includes the library

Solution 2: Application approach

An application should have full control, therefore we use values specified in the application. A common scenario could be that a user has a library which he uses in another application and the testing of the library is done by using it in the application, therefore all warnings should be reported, debugs, trace, profile could be enabled, assertion level may be higher.

Example for various solutions

Config example.png

Simplified configuration system of the compiler. ES is EiffelStudio (the application), vision2 is the graphic library used by ES which internally uses WEL. The application and all libraries use base.

Library approach

Base, vision2, wel set the options and those options are used. The options of base and vision2 can be overridden (but they have to be overridden for each library separately), wel can not be overridden (unless it is included in the application directly).

Application approach

All the options are specified in ES, it's possible to specify specific values for the used libraries that are directly included, otherwise the default values from the application will be taken.