ECLiPSe source files can be compiled into ECLiPSe object files, for subsequent loading. These files have the .eco suffix by default. This facility is mainly intended for module files. To create such a file, call the compiler with the appropriate output-option, e.g.
?- compile(myprogram, [output:eco]).
This create a precompiled file myprogram.eco from a source file called myprogram.ecl (or myprogram.pl). If the source file contained include directives, the result will be a single object file containing the compiled code of all included files. In earlier releases of ECLiPSe this was done using the fcompile/1 predicate from the fcompile library, which is still supported for compatibility.
Loading of ECLiPSe object files is significantly faster than compilation from source. In ECLiPSe 6.0, ECLiPSe object files are text files containing a representation of the compiled abstract machine code, and can be used to deploy application code without revealing the source. The precompiled code is hardware and operating system independent. It may however not be portable between different versions of ECLiPSe if details of the abstract machine were modified between releases.
The file suffix used for ECLiPSe object files is the value of the global flag eclipse_object_suffix.
Currently, the compiler generates the auxiliary predicates for the do iterator using a module-wide counter to name the predicates. Unfortunately this means that if an object file with auxiliary predicates is loaded into a module that already has existing code that contains auxiliary predicates, naming conflict can occur and the old auxiliaries may be replaced. It is thus strongly recommended that object files should not be loaded into an existing module. This will only be a problem if the file does not contain any module declarations that redefines the module (i.e. module/1), as these redefinition will erase the old copy of the module.
One restriction does apply between platforms of different
word sizes: integers which fit in the word size of one platform
but not the other are represented differently internally in ECLiPSe.
Specifically, integers which takes between 32 and 64
bits to represent are treated as normal integers on a 64 bit machine,
but as bignums (see section 8.2.1) on 32 bit machines. This
difference is normally invisible, but if
such numbers occur as constants in the program code (i.e. their values appear
textually), they can lead to different low-level compiled abstract code on
the different platforms. Avoid using such constants if you want
the object code to be portable across different word sizes (they can always
be computed at run-time, e.g. writing 2^34
instead of 17179869184).
The following predicates either invoke the compiler or load precompiled .eco files. If the source specification does not specify the file type, precompiled files are preferred if they can be found in the search path:
To implement reloading/recompiling when needed, the system keeps track of when a particular source files was compiled or precompiled file was loaded into memory. This information can be accessed explicitly through current_compiled_file/3.
To generate .eco file from source files, the compiler can be run from the command line using the -e option. To invoke it from a makefile, use the following suffix rule
.SUFFIXES: $(SUFFIXES) .ecl .eco .ecl.eco: eclipse -e "compile(\"$<\",[output:eco])"
or a pattern rule for Gnu make:
%.eco: %.ecl eclipse -e "compile(\"$<\",[output:eco])"