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: | %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
These 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.