[ISE Home] [ Home ] [ Release Notes ] [ Technology Papers ] [ Installation Notes ] [ About Eiffel ]

Introduction

We reproduced below an example of an Ace file generated by EiffelBench when one choose `Build' from the Ace file builder. We will use this as an example to explain all ace file options.

system
	sample

root
	ROOT_CLASS: "make"

default
	address_expression (no)
	array_optimization (no)
	assertion (all)
	check_vape (yes)
	console_application (no)
	collect (yes)
	dead_code_removal (yes)
	debug  (no)
	debug ("DEBUG_TAG")
	document (".")
	dynamic_runtime (no)
	exception_trace (no)
	inlining (yes)
	inlining_size ("4")
	line_generation (no)
	multithreaded (no)
	override_cluster("your_override_cluster")
	profile (no)
	shared_library_definition ("file_name.def")
	precompiled ("$EIFFEL5\precomp\spec\$PLATFORM\base");

cluster
	root_cluster: "c:\temp";

		-- EiffelBase
	all base:	"$EIFFEL5\library\base"
		exclude
			"desc";"table_eiffel3"
		end

	thread:	"$EIFFEL5\library\thread"

external
	include_path:
		"$(EIFFEL5)\library\wel\spec\windows\include"
	object:
		"$(EIFFEL5)\library\wel\spec\$(COMPILER)\lib\wel.lib"
end

Lace default options

We will describe each option as they are presented in the Ace file above. The default option is shown in bold.

• address_expression (yes | no): enables you to pass `$(s.to_c)' to a feature instead of declaring `a' of type ANY, and then assigning `s.to_c' to `a' and passing `$a'.
• array_optimization (yes | no): enables array optimization which increases performances of array computation in loops. It is enabled only if arrays are used as local or argument of an Eiffel feature.
• assertion (no | require | ensure | invariant | loop | check | all): sets the assertion level of an Eiffel system. Each level includes the previous level, thus specifying `loop' will also check for preconditions, postconditions, class invariants, loop variants and loop invariants.
• check_vape (yes | no): enables you to disable type checking for VAPE errors in preconditions (ETL 2nd edition page 122).
• console_application (yes | no); has no effects on Unix and it has been made for Windows users. It enables Windows users to choose between creating a console application or a GUI application.
• collect (yes | no): not applicable. One has to use the MEMORY class to activate or stop the garbage collector.
• dead_code_removal (yes | no): it is a finalization option only. It enables you to not generate the C code for Eiffel routines that are not called in your code, and thus reducing the size of the generated application.
• debug (yes | no | "DEBUG_TAG"): enables you to activate or disable the code written inside `debug' statement in your Eiffel code. If you marked your code with tagged `debug' statement and if you specify the tag in the Ace file, only the kind of `debug' statement will be executed.
• document ("path"): when generating the documentation from EiffelBench (`Special' menu, then `Documentation' then `Flat', `Flat-short', `Short' or `Text'), it will generate it to the `path' directory. If not specified the documentation will be generated at the same level of your EIFGEN directory in a directory called `Documentation'.
• dynamic_runtime (yes | no): enables the use of shared library version of the runtime on both Windows (DLL) and Unix platforms that supports shared library (click here to have the details for your platform),
• exception_trace (yes | no): it is a finalization option only. It enables you to see a complete exception trace when your finalized application is crashing. Because it is adding some code to remember where the application was during the crash it can slow down the performance of your application by a factor of 5% to 30% depending of your platform.
• inlining (yes | no): it is a finalization option only. It enables to inline functions that can be inlined (see `inlining_size' below). The ISE Eiffel inlining is very powerful since it can inline a function to all your Eiffel code, there is no scope limitation as in C or C++ compilers.
• inlining_size ("value"): it is a finalization option only. It enables to specify the size which tells the compiler that a function can be inlined or not. The value given in parameter corresponds to the number of instructions as the Eiffel compiler see them (for example a := b.f corresponds to 2 instructions for the Eiffel compiler).
• line_generation (yes | no): enables the generation of C pragmas `#line x' in the C generated code. This options is mostly used by embedded Eiffel developers who could not run the ISE EiffelBench environment on their target platform.
• multithreaded (yes | no): enables the generation of a multithreaded application. This option cannot be changed during the development of your project and has to be set correctly at the first compilation of your system.
• override_cluster (cluster_name): enables you to specify a certain `cluster_name' as override cluster. As a result, all classes in `cluster_name' will override the classes with the same names located in other clusters. Very useful when used in conjunction with configuration management tools.
• profile (yes | no): enables the Eiffel profiling (to know more about Eiffel profiling click here).
• shared_library_definition ("file_name.def"): enables you to specify `file_name.def' as file where the Eiffel compiler will look when trying to generate the exported function of the shared library you are developing.
• precompiled ("precompiled_library_path"): enables you to specify a precompiled library. Most examples given in the ISE EiffelBench delivery are using a precompiled library. It makes the development of small application incredibly fast.

External options

• include_path: enables you to specify the path to the header files you are using in external clauses of your Eiffel based source code.
• object: enables you to link your application with specified object files.

Lace keywords

Introduced with ISE EiffelBench 4.5 the keyword `all' can now appear before the name of a cluster. This new keyword is now used in most Ace files given with your distribution. On example can be found above and it is reproduced below with some explanations:

	-- EiffelBase
all base: "$EIFFEL5\library\base"
	exclude
		"table_eiffel3"
	end

The meaning of `all' is to take into account all Eiffel files located below the directory pointed by the `base' cluster. In addition, the example above uses `exclude' make sure that the directory called `table_eiffel3' won't be traversed. This is very useful when you have two clusters which are used through a switch in your Ace file.