[Ecls-list] Trying to compile defsystem

[Marco Antoniotti]

> From: Juan Jose Garcia Ripoll <worm at arrakis.es>
> Reply-To: worm at arrakis.es
> Date: Thu, 14 Nov 2002 12:06:51 -0800
> Cc: Marco Antoniotti <marcoxa at cs.nyu.edu>
> X-MIME-Autoconverted: from quoted-printable to 8bit by cat.nyu.edu id gAEB5Mqs020328
> X-UIDL: cM("!CL0!!\9R"!mh8"!
> 
> > I also tried the patched version Juan José Garcia Ripoll posted at
> > <http://ecls.sourceforge.net/download.html>. This one compiles but it
> > didn't get me much further:
> >   Cannot find the external symbol *CENTRAL-REGISTRY* in #<"MAKE" package>.
> 
> I am awfully sorry. I should have checked the port more extensively. It is 
> good porting packages, because a lot of errors arise. Now I have found a bug 
> in the implementation of logical pathnames. Namely, a logical pathname 
> #p"home:foo.lisp" did not match against the filter #p"home:**;*.*". I am 
> fixing this right now, and introducing the logical hostname "HOME", for 
> compatibility with other implementations.
> 
> When this is done, I will submit further patches for defsystem-3 to Marco 
> Antoniotti for inclusion in CLOCC.
> 
> It also puzzles me how to improve defsystem.lsp in order to handle
> better the 
> way ECL works. Namely, ECL may either compile each *.lsp file to a separate 
> DLL, or it may compile each *.lsp file to an *.o file which can be linked 
> together into a single DLL. Personally I prefer the last approach, but I do 
> not know enough of defsystem-3 to get this done. Any hints? I really would 
> like to integrate ECL and defsystem together.

Currently you could achieve that by adding a :finally-do function
in your DEFSYSTEM form

   (mk:defsystem "FOO"
      :components (...)
      :finally-do (combine-the-compiled-files-in-a-shared-lib
                     (mk:files-in-system "FOO")))

This is what the MATLISP folks do when handling the FORTRAN libraries
with MK:DEFSYSTEM.

Note that the above may not be completely portable; meaning that your
DEFSYSTEM forms will then be dependent on the fact that they are
targeted to ECL.


MK:DEFSYSTEM 4 has (somewhat) the infrastructure in place to allow
this extension.  MK4 (module `defsystem-4.x' in CLOCC CVS) has a KMP
architecture.  A call to OOS is transformed (as expected) in a
traversal of the current dependency tree where the method
EXECUTE-ACTION is applied at each component.

The actual call to the underlying compiler is masked by a call to the
method COMPILE-ACTION, which (1) can be retargeted to the specific
implementation and (2) gives you the necessary hook (via :AFTER
methods) to actually attach the code you need to achieve something
like what you describe before.

All of this brings up an ambiguity in the definitions of the items in
a system.  If you have a "library", eventually to be rendered as a
"lib.dll" or a "lib.so" or a "lib.a", are the files that go into it
"sub components" or "dependencies" ?

Somehow I opted for the "components" approach.  I think it makes more
sense, although the implementation becomes more cumbersome.

Cheers


-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
715 Broadway 10th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.