[Ecls-list] Dumping running image
Juan Jose Garcia-Ripoll
jjgarcia at users.sourceforge.net
Sun Mar 11 11:20:12 UTC 2007
11 Mar 2007 05:25:04 -0500, Gabriel Dos Reis <gdr at cs.tamu.edu>:
> In the system I'm working with, I have the following scenario:
> (I) one part does the following:
> (1) the system defines some macros
> (2) those macros need to be present in the environment while
> compiling the rest of the files.
> (3) with GCL, SBCL, CLISP the system builds fine as follows:
> (a) load the macros in a fresh lisp.
> (b) save the current image to disk.
> (c) use that image to compile the rest of the files.
> (d) use that image to load all objects and build the
> final executable.
(1) Build an program with the macro files. Call it ECL2
(2) For each file, use ECL2 to compile it.
(3) Build a program with the macro and the compiled files.
(II) another part does this for bootstrapping:
> (1) start with loading macros
> (2) for each file in a component II:
> (a) compile the lisp file to object code
> (b) load the just compiled object code
> (3) save the resulting image to disk.
Here it would apply the same routine as before. Build an ECL2 that contains
the macros. For each file, compile it twice: once as a FASL, once as object
file (with :system-p t). Load the FASL and continue compiling. Finally link
all the object files (macro and compiled files) into a single executable.
If you do things this way, the resulting standalone program will mimic the
steps of first loading the macros and then loading each FASL. If your system
supports this way of working then it should work with ECL.
for timing constraints, it is important that the loading of object
> files doe not go from linear to quadratic.
I do not understand this very well.
Dpto. de Fisica Teorica I, Fac. de CC Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ecl-devel