Configuration file

Most LibertyEiffel tools need some kind of configuration which is stored in a unique file to allow the user not too have over-long command lines ;-)

In particular it contains

• general settings like system type, number of processes to start during compilation
• paths to find tools, environment variables, short templates...
• paths of the clusters that define all the classes available by default (the universe).
• se shortcuts for the available tools
• C-compiler options for each c_mode

An initial version of this configuration is generated by the installation tool of LibertyEiffel.

Where is this configuration

It is possible to have several configuration files, which are treated by priority and more specific files can override the settings from the general ones. The lowest priority is attributed to system-wide files, while user-specific (e.g. ~/.serc) and session-specific (the Liberty environment variable) get higher priority. In case a configuration location is a directory, all the entries of the directory are merged (or to be accurate: all entries are handled with priority defined via alphabetical sort of the names). All that because of some distributions like to add/remove files instead of grep'ing and sed'ing huge configuration file. Default configuration file locations:

Windows and DOS:	C:\SE.CFG, C:\LIBERTY.CFG, %ALLUSERSPROFILE%\Liberty-Eiffel, %USERPROFILE%\SE.CFG, %USERPROFILE%\LIBERTY.CFG, %USERPROFILE%\Liberty-Eiffel (lookup in this order)
Unix and Cygwin:	/etc/serc, /etc/xdg/liberty-eiffel, /etc/liberty-eiffel, /usr/local/etc/liberty-eiffel, ~/.config/liberty-eiffel, ~/.serc ~/.liberty-eiffel (look-up in this order, XDG_CONFIG_HOME is taken into account to adjust the paths)
Elate:	/lang/eiffel/serc

The suggested directories are bold.

The other operating systems don't have a default value, the Liberty environment variable must be used. If you have such an operating system and you think there is a reasonable default value, thanks for telling us.

File syntax

The file is written using a simple text format. It is split in sections that each begin with a word between square brackets on a single line. Each section is comprised of key-value pairs separated by a colon.

Example:

[General]
bin: /home/cyril/Liberty/bin/
sys: /home/cyril/Liberty/sys/
short: /home/cyril/Liberty/short/
os: UNIX
flavor: Linux
tag: 3
jobs: 4

The General section

This section is named [General]. It must provide the following keys:

bin	the path to the compiler executables. This path is used in particular by the se tool (see below the Tools section) and compile.
sys	the path to the LibertyEiffel system files. This path is used by compile_to_c. It contains all the basic files included by those compilers. They define the "basic bricks" of the generated Eiffel system.
short	the path to the short templates (modes -html, -tex, etc.)
os	the type of the operating system LibertyEiffel is installed on. The recognized types are: UNIX, Windows, Cygwin, BeOS, Macintosh, Amiga, DOS, OS2, OpenVMS, Elate.
flavor	allows a more accurate specification of the operating system type, useful for some plugins. For instance, if the os is UNIX, the flavor can be Linux. There is no predefined list of values; plugins must tell which are the supported flavors.
tag	normally only used by the installation tool to define the version of the configuration file. There should be ascending compatibility between versions but currently, if the tag is not the one of the installation tool, no data is kept. This behavior was changed in SmartEiffel 2.3, to keep as much data as possible. The tag value was 3 for SmartEiffel 2.2 and 2.3.
jobs	if a tool has some tasks which may be done in parallel (e. g. calling the C compiler for generated C files) it creates at most the configured amount of processes. Performance-wise, it's likely best not to use hyperthreading, especially when compiling big systems. An example: if your system reports a quadcore processor, it might actually be equipped with a dualcore with hyperthreading activated. In that case it's likely best to set jobs to 2 and not to 4.

The Environment section

The environment section allows you to define environment variables specific to LibertyEiffel. In particular these variables are available in the remaining of the configuration file, in the loadpath.se files, ACE files and some command line arguments.

The installation tool installs the following default variables:

[Environment]
path_liberty: /home/cyril/Liberty/
path_liberty_core: /home/cyril/Liberty/src/lib/
path_liberty_extra: /home/cyril/Liberty/src/wrappers/
path_smarteiffel: /home/cyril/Liberty/src/smarteiffel/
path_tools: /home/cyril/Liberty/src/tools/
path_tutorial: /home/cyril/Liberty/tutorial/

Note that anyone can add their own variables.

The universe

The universe is the set of all known clusters. It is defined in the [Loadpath] section.

The installation tool installs the following default universe:

[Loadpath]
liberty_core: ${path_liberty_core}loadpath.se
liberty_extra: ${path_liberty_extra}loadpath.se
test: ${path_liberty}test/loadpath.se
smarteiffel: ${path_smarteiffel}loadpath.se
tools: ${path_tools}loadpath.se
tutorial: ${path_tutorial}loadpath.se

Note that anyone can add their own tools to the libraries they use most.

Caveat: the universe is not used by the tools if an ACE file is given. In this case, the ACE file must describe the whole universe. On the other hand it is very simple to do so since just adding a single line or two to your ACE file will produce the desired effect:

cluster
   standard: "${path_liberty_core}loadpath.se"

Tools

All the tools used by the se command are set here. These tools must be in the directory pointed to by the bin key of the [General] section. The key is used as first argument of se.

The installation tool installs the following default commands:

[Tools]
ace_check: ace_check
c2c: compile_to_c
c: compile
class_check: class_check
clean: clean
doc: eiffeldoc
find: finder
make: se_make.sh
mock: mocker
pretty: pretty
short: short
test: eiffeltest
test_ng: eiffeltest_ng
test_server: eiffeltest_server
wrap: wrappers_generator
x_int: extract_internals

Note that anyone can add their own tools, as long as the executable is in the directory pointed to by the bin key of the [General] section and an entry is added to the [Tools] section.

C modes

Those modes are used by the C back-end: used C compiler, options... E. g.

[boost]
c_compiler_type: gcc
c_compiler_path: gcc
c_compiler_options: -pipe -O2 -fno-gcse
c_linker_path: gcc
c_linker_options: -Xlinker -no-as-needed
cpp_compiler_type: g++
cpp_compiler_path: g++
cpp_compiler_options: -pipe -O2 -fno-gcse
cpp_linker_path: gcc
cpp_linker_options: -Xlinker -no-as-needed

By default some C modes are automatically associated to the Eiffel compilation levels (-boost, -require_check, etc.). The C mode can also be explicitely set in the command line of compile_to_c or compile thanks to the -c_mode option.

The following C modes are default for a standard installation: boost, no_check, require_check, ensure_check, invariant_check, loop_check, all_check, debug_check and release. Only the last one must be explicitely set; it is usually used to finalize a program (se c -boost -c_mode release ...)

Usually the default C modes depend on the chosen C compiler and needs adaption if GCC is not used.