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

[Mark Murray]

root writes:
> >  - Tim prefers to have a big sources with all included dependencies in
> >    order to control the built system;
> 
> that's correct. Axiom is a very complex beast (probably over a million
> lines in the fully developed system). It is very version dependent for
> many subsystems, including GCL. In order to keep the quality of the
> system at a high level the system is built and tested with particular
> versions of GCL. In fact, a great deal of effort goes into making sure
> that it works with the latest version. Axiom periodically takes 
> snapshots of the GCL CVS in order to get the latest version. The
> snapshots are then modified during the build. 

This bit makes it very hard to port :-). Would it be possible check in
an _untarred_ GCL? The current method of tarball+patches makes it hard
to have patches of our own, particularly when they conflict with yours.

> It is possible, if you have locally modified GCL, to replace the
> GCL snapshot version (it is in src/zips) with your local version
> but I can't guarantee that Axiom will work. I've tried to fully
> document every change for every version of GCL with a complete
> explanation so you can understand the what and why. The documentation
> is in the various Makefile.pamphlet files (see the Makefile.dvi).

Yeah. :-( I had GCL-current working for ages, but in a conflict-merge
I seem to have broken something (perhaps).

> >  - it is possible to build Axiom with an external GCL. In fact, Camm
> >    Maguire, lead GCL developer and debian packager of gcl, axiom, maxima
> >    and other software, is doing exactly that for the axiom debian
> >    package. I don't know however if the machinery has been included in
> >    current sources of Axiom.
> 
> that's not strictly correct. Axiom will not fully run on an external GCL.

It needs patches, which Camm gave me a year or so ago, and which are now
broken. (Maybe).

> depending on what you are doing it will fail. in particular, axiom adds
> special socket handling code to GCL which will be used by the newly added
> graph capabilities. further, axiom has special build-time flags (documented
> in the top level Makefile) that need to be set to your particular version
> of GCL. If you are not using the same version that is included with the
> Axiom CVS you need to change these flags and rebuild your local version.

Not strictly true; GCL can load code fragments, and an external build of
GCL build Axiom successfully for me for a long time.

> in addition to sockets Axiom is adding code to do machine-level numeric
> support. i have a local version (not yet documented, tested, and checked in)
> which contains support for BLAS (Basic Linear Algebra Subroutines). These
> are built into the GCL image at system build time. Axiom's numerics will
> depend on these routines as well as additional routines that are in the
> queue to add. There has been some discussion about pushing the numerics
> support into GCL as Camm is also the BLAS maintainer. Since Axiom is
> currently the only user it is not clear that GCL wants or needs them.

You should be able to to the GCL dlopen(3) equivalent load of stuff like that.

> A third package is also in my local version that is going to be added
> which requires GCL changes. I've been working with ltk. This is a 
> lisp TK toolkit that runs on almost every lisp (except, it seems, GCL).
> The current GCL/TK package is broken as far as I can tell. I can get it
> to work but it promptly crashes. We're working on a new Axiom GUI to
> replace the lost techexplorer and it is being developed using TCL/TK.
> Since the current GCL/TK doesn't work and ltk is almost all native
> common lisp we're going to use it going forward. Hopefully once it
> runs I can convince Camm to support it also but, again, since Axiom is
> the only user it is not clear that it is worth adding it to GCL.

dlopen equivalent?

> so it is unlikely, going forward, that Axiom will run on your installed
> version of GCL.

... without a bit of work :-)

M
--
Mark Murray
iumop ap!sdn w,I idlaH