Difference between revisions of "Compile to c"
Hzwakenberg (talk | contribs) |
Hzwakenberg (talk | contribs) m |
||
(8 intermediate revisions by 2 users not shown) | |||
Line 19: | Line 19: | ||
The <TT>[[compile_to_c]]</TT> command produces the C files (<TT>*.h</TT> and <TT>*.c</TT>). A script file is also created, whose name depends on the application. This is a <TT>.make</TT> file (under UNIX) or a <TT>.BAT</TT> file (under DOS/Windows). |
The <TT>[[compile_to_c]]</TT> command produces the C files (<TT>*.h</TT> and <TT>*.c</TT>). A script file is also created, whose name depends on the application. This is a <TT>.make</TT> file (under UNIX) or a <TT>.BAT</TT> file (under DOS/Windows). |
||
− | The <TT>[[compile_to_c]]</TT> command must have at least one argument which specifies the program's starting point; this is in fact a class's creation procedure. In ACE mode this data is obtained from parameters in the ACE file. In traditional mode, at least the class name must be specified; the default name of the creation class is <TT>make</TT>, which has to exist; otherwise, the creation |
+ | The <TT>[[compile_to_c]]</TT> command must have at least one argument which specifies the program's starting point; this is in fact a class's creation procedure. In ACE mode this data is obtained from parameters in the ACE file. In traditional mode, at least the class name must be specified; the default name of the creation class is <TT>make</TT>, which has to exist; otherwise, the creation feature must be specified. |
− | In all cases, the creation |
+ | In all cases, the creation feature must be one ''without arguments''. |
=== Loading Eiffel files === |
=== Loading Eiffel files === |
||
Line 40: | Line 40: | ||
|- |
|- |
||
| valign="top" | <code>-version</code> |
| valign="top" | <code>-version</code> |
||
− | | Display the |
+ | | Display the Liberty Eiffel version number. |
|} |
|} |
||
Line 48: | Line 48: | ||
There are the following compilation modes which give different levels of assertion checking. In ascending order of verification they are: |
There are the following compilation modes which give different levels of assertion checking. In ascending order of verification they are: |
||
− | * '''boost''' is a mode in which ''no'' validity checking is done and in which |
+ | * '''boost''' is a mode in which ''no'' validity checking is done and in which Liberty Eiffel does '''additional processing''' compared to the other modes. In particular, in this mode: |
− | ** the execution stack is not managed by |
+ | ** the execution stack is not managed by Liberty Eiffel, |
** the behavior of certain language constructs is changed: |
** the behavior of certain language constructs is changed: |
||
*** no tests for Void (which leads to a segfault if there is any problem...) |
*** no tests for Void (which leads to a segfault if there is any problem...) |
||
Line 55: | Line 55: | ||
*** if <TT>else</TT> is missing from an <TT>inspect</TT> clause, the last branch is used for <TT>else</TT>, |
*** if <TT>else</TT> is missing from an <TT>inspect</TT> clause, the last branch is used for <TT>else</TT>, |
||
** <TT>and</TT> and <TT>or</TT> become semi-strict (i.e. the second expression may not be evaluated if the first expression is enough to infer the result of the <TT>and</TT> or <TT>or</TT> expression, like <TT>and than</TT> and <TT>or else</TT>) |
** <TT>and</TT> and <TT>or</TT> become semi-strict (i.e. the second expression may not be evaluated if the first expression is enough to infer the result of the <TT>and</TT> or <TT>or</TT> expression, like <TT>and than</TT> and <TT>or else</TT>) |
||
− | ** |
+ | ** Liberty Eiffel does an optimization pass; in particular, certain functions are inlined; |
* '''no_check''' is a mode in which no validity checking is done, but the above optimizations are not done (in particular, the execution stack is always managed, the <TT>Void</TT> tests and type checks are always done, and so on); |
* '''no_check''' is a mode in which no validity checking is done, but the above optimizations are not done (in particular, the execution stack is always managed, the <TT>Void</TT> tests and type checks are always done, and so on); |
||
* '''require_check''' is a mode in which only the preconditions are checked; |
* '''require_check''' is a mode in which only the preconditions are checked; |
||
Line 103: | Line 103: | ||
{| cellspacing="4" cellpadding="0" width="100%" |
{| cellspacing="4" cellpadding="0" width="100%" |
||
|- |
|- |
||
− | | width="20%" valign="top" | <code>- |
+ | | width="20%" valign="top" | <code>-style_warning</code> |
− | | |
+ | | Display warning messages about non-compliance with Eiffel style rules. |
|- |
|- |
||
| valign="top" | <code>-no_warning</code> |
| valign="top" | <code>-no_warning</code> |
||
− | | Suppress all warning messages |
+ | | Suppress all warning messages. |
+ | |} |
||
+ | |||
+ | ==== Message Styles ==== |
||
+ | |||
+ | {| cellspacing="4" cellpadding="0" width="100%" |
||
+ | |- |
||
+ | | width="20%" valign="top" | <code>-flymake_mode</code> |
||
+ | | Display messages in a compact format suitable for processing by tools such as Emacs' Flymake mode. |
||
|} |
|} |
||
Line 131: | Line 139: | ||
|- |
|- |
||
| valign="top" | <code>-relax</code> |
| valign="top" | <code>-relax</code> |
||
+ | | Perform fewer checks by considering less dead code, hence using less memory and less compilation time. Useful to prototype or to deliver safe code. (Useful too for very small computers.) |
||
− | | '''?????''' <!-- Philippe or Dominique, please complete this --> |
||
|} |
|} |
||
Line 154: | Line 162: | ||
When this option is used, the garbage collector is not produced and (at least) one <TT>malloc()</TT> is done for each object creation. This option is useful if you want to use another garbage collector from an external library, or when a garbage collector is not needed. |
When this option is used, the garbage collector is not produced and (at least) one <TT>malloc()</TT> is done for each object creation. This option is useful if you want to use another garbage collector from an external library, or when a garbage collector is not needed. |
||
− | Without this option, |
+ | Without this option, Liberty Eiffel builds a garbage collector tailored to the application or the BDW GC. |
|- |
|- |
||
| valign="top" | <code>-bdw_gc</code> |
| valign="top" | <code>-bdw_gc</code> |
||
Line 160: | Line 168: | ||
|- |
|- |
||
| valign="top" | <code>-gc_info</code> |
| valign="top" | <code>-gc_info</code> |
||
− | | When this option is used, the [[garbage collector]] displays |
+ | | When this option is used, the [[garbage collector]] displays information about its use at run time. |
|- |
|- |
||
| valign="top" | <code>-cecil <cecil_file></code> |
| valign="top" | <code>-cecil <cecil_file></code> |
||
Line 166: | Line 174: | ||
|- |
|- |
||
| valign="top" | <code>-no_main</code> |
| valign="top" | <code>-no_main</code> |
||
− | | Do not generate a <TT>main()</TT> C function. In this case the root creation |
+ | | Do not generate a <TT>main()</TT> C function. In this case the root creation feature is not called. This can be useful when you want to start execution from outside before calling Eiffel routines via the [[cecil]] interface. |
Before calling the first Eiffel routine, do not forget to call the routine <TT>initialize_eiffel_runtime(argc, argv);</TT> which initialises the Eiffel system. |
Before calling the first Eiffel routine, do not forget to call the routine <TT>initialize_eiffel_runtime(argc, argv);</TT> which initialises the Eiffel system. |
||
|- |
|- |
||
| valign="top" | <code>-sedb</code> |
| valign="top" | <code>-sedb</code> |
||
− | | This option allows you to include the [[sedb| |
+ | | This option allows you to include the [[sedb|Liberty Eiffel debugger]] in your executable. |
|- |
|- |
||
| valign="top" | <code>-profile</code> |
| valign="top" | <code>-profile</code> |
Latest revision as of 16:21, 7 July 2024
The compile_to_c command is the ANSI C code generator. This command is usually called automatically from compile, but you can also use it on its own to produce the C code. Like compile, there are two ways of running it: traditional mode and ACE mode.
- In traditional mode, many options can be given on the command line.
- In ACE (Assembly of Classes in Eiffel) mode, most of its options are not allowed on the command line; but they have equivalents in the ACE file.
Synopsis
se c2c [options] <root_class> [<root_procedure>]
se c2c [common_options] <ace_file.ace>
The first usage is traditional mode; the second is ACE mode.
In ACE mode, the name of the ACE file must end with the suffix .ace.
The compile_to_c command produces the C files (*.h and *.c). A script file is also created, whose name depends on the application. This is a .make file (under UNIX) or a .BAT file (under DOS/Windows).
The compile_to_c command must have at least one argument which specifies the program's starting point; this is in fact a class's creation procedure. In ACE mode this data is obtained from parameters in the ACE file. In traditional mode, at least the class name must be specified; the default name of the creation class is make, which has to exist; otherwise, the creation feature must be specified.
In all cases, the creation feature must be one without arguments.
Loading Eiffel files
The compile_to_c command uses the same process as finder to find and load the Eiffel files to compile. Note that, as with finder, the process differs according to whether you are using traditional or ACE mode.
Common options
These options can be used both in ACE mode and in traditional mode.
-help
|
Display a short summary of the command line syntax, with a complete list of the compiler options. |
-verbose
|
Display (an enormous amount of) information during compilation: a complete trace of files loaded, type inference scores, generated files and so on. |
-version
|
Display the Liberty Eiffel version number. |
Options specific to traditional mode
Compilation mode
There are the following compilation modes which give different levels of assertion checking. In ascending order of verification they are:
- boost is a mode in which no validity checking is done and in which Liberty Eiffel does additional processing compared to the other modes. In particular, in this mode:
- the execution stack is not managed by Liberty Eiffel,
- the behavior of certain language constructs is changed:
- no tests for Void (which leads to a segfault if there is any problem...)
- no tests for type conformity (ditto; cf the forced assignment operator ::=)
- if else is missing from an inspect clause, the last branch is used for else,
- and and or become semi-strict (i.e. the second expression may not be evaluated if the first expression is enough to infer the result of the and or or expression, like and than and or else)
- Liberty Eiffel does an optimization pass; in particular, certain functions are inlined;
- no_check is a mode in which no validity checking is done, but the above optimizations are not done (in particular, the execution stack is always managed, the Void tests and type checks are always done, and so on);
- require_check is a mode in which only the preconditions are checked;
- ensure_check is a mode in which the preconditions and postconditions are checked;
- invariant_check is a mode in which the preconditions, postconditions and class invariants are checked;
- loop_check is a mode in which the preconditions, postconditions and class invariants are checked and loop variants and invariants are checked as well;
- all_check is a mode in which all assertions (those above and the check clauses) are checked;
The following minor modes may be combined with the compilation modes above:
- flat_mode each assertion will be executed in no_check mode (non-recursive assertion checking), use in combination with any mode from require_check to all_check
- debug_mode Compile debug blocks. This mode may be used in combination with any other compilation mode.
-boost
|
Activate boost mode. |
-no_check
|
Activate no_check mode. |
-require_check
|
Activate require_check mode. |
-ensure_check
|
Activate ensure_check mode. |
-invariant_check
|
Activate invariant_check mode. |
-loop_check
|
Activate loop_check mode. |
-all_check
|
Activate all_check mode. |
-debug_check
|
Activate all_check and debug mode. This is deprecated as it is equivalent to -all_checkk -debug. |
-debug
|
Compile debug blocks. This flag may be used with any other assertion level flag. |
Warnings
These options affect the compilation process, but do not change the generated C code.
-style_warning
|
Display warning messages about non-compliance with Eiffel style rules. |
-no_warning
|
Suppress all warning messages. |
Message Styles
-flymake_mode
|
Display messages in a compact format suitable for processing by tools such as Emacs' Flymake mode. |
Advanced options
Not affecting the generated C code
These options affect the compilation process, but do not change the generated C code.
-o <executable>
|
Specify the name of the executable program. |
-loadpath <loadpath_file>
|
Add a file containing Eiffel class search paths. For details see the finder command. |
-no_strip
|
Do not strip symbol data from the executable file. This option is useful for debugging the C code (either generated or included code). |
-high_memory_compiler
|
Allow the compiler to use more memory... This can allow faster compilation, if you have enough RAM. |
-relax
|
Perform fewer checks by considering less dead code, hence using less memory and less compilation time. Useful to prototype or to deliver safe code. (Useful too for very small computers.) |
Affecting the generated C code
These options change the generated C code.
-c_mode <C_mode>
|
Use a different C mode. |
-cc <C_compiler>
|
Call the specified C compiler instead of the one in the default configuration. This option is incompatible with <-c_mode> and should generally be avoided except under very special circumstances. |
-no_split
|
Produce a single C file containing the entire application. This can allow the C compiler to do a lot of optimisation and is therefore useful for the production stage of a project. This option is usually implied if you use -c_mode release. |
-no_gc
|
No garbage collector.
When this option is used, the garbage collector is not produced and (at least) one malloc() is done for each object creation. This option is useful if you want to use another garbage collector from an external library, or when a garbage collector is not needed. Without this option, Liberty Eiffel builds a garbage collector tailored to the application or the BDW GC. |
-bdw_gc
|
When this option is used, the Boehm-Demers-Weiser garbage collector is used instead of the traditional "SE GC". |
-gc_info
|
When this option is used, the garbage collector displays information about its use at run time. |
-cecil <cecil_file>
|
Allow Eiffel features to be called from C (see cecil for details). |
-no_main
|
Do not generate a main() C function. In this case the root creation feature is not called. This can be useful when you want to start execution from outside before calling Eiffel routines via the cecil interface.
Before calling the first Eiffel routine, do not forget to call the routine initialize_eiffel_runtime(argc, argv); which initialises the Eiffel system. |
-sedb
|
This option allows you to include the Liberty Eiffel debugger in your executable. |
-profile
|
This option allows you to include the profiler in your executable. |
-manifest_string_trace
|
This option allows you to include in your executable a trace of the creation of manifest strings. This can be useful for tracking down some memory errors. |
Options passed to the C compiler
All unrecognised options are passed to the C compiler.
Generation
(to be completed...). See C code generation