Re: Axiom & internal/external GCL (was: Re: [Axiom-developer] Axiom cvs 040624 build error)

[root]

Camm,

> I believe that every GCL patch/add-on currently utilized by axiom can
> be incorporated without reference to the gcl source, rather simply
> having gcl installed in binary form.

I'm sure it's possible, in fact I'm certain it is possible. 
What it implies is that somebody (likely me) will have to take the
various C routines that Axiom depends upon, code some lisp above
them to talk to GCL, rework the Makefiles to compile and add the
routines at the appropriate build time, and document the process. 

I think this is the correct and elegant path to take.

However, to be truly elegant, it should be the case that the same
approach (not the same code) should be generic enough to work in
several lisps, in particular, for GCL, CCL, and CMUCL. 

Since the lisp is working at the moment and things like graphics
are not I don't have the cycles to go back and figure out a general
mechanism. When I get back to porting issues at the lisp level I'm
certain to take a whack at this problem as it is clearly a "community
issue" and my design choice is crimethink.

It may even get solved "looking forward" as I've done some work with
axiom's numerics and want to figure out a general mechanism to include
BLAS, LAPACK, QUADPACK, etc. Clearly I'd be foolish to link them into
the image at compile time.

The issue is time and learning, not intransigence.

If someone is willing to strip out Axiom's C routines, write them up
as a dynamically linkable .lsp file (in isolation, without the rest of
axiom) and send them to me I'll struggle with the rest of the tasks.

t