axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Axiom & internal/external GCL (was: Re: [Axiom-developer]Axiomcvs 04


From: Camm Maguire
Subject: Re: Axiom & internal/external GCL (was: Re: [Axiom-developer]Axiomcvs 040624 build error)
Date: 28 Jun 2004 18:54:31 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

root <address@hidden> writes:

> > > I think, we should unbundle gcl and other additional
> > > software. To get Axiom running and some gcl interactions 
> > > resolved, it was certainly ok to pack everything together in 
> > > the beginning. But these problems should be solved now. Most 
> > > package systems (debian, BSDs etc) expect that the lisp 
> > > system and other packages are separate. Besides it will
> > > make Axiom much easier to port to other platforms. The
> > > technical details of loading C code have already been
> > > adressed in Camm's mails. 
> > 
> > I agree with this. It is normal practice for complex systems
> > like Axiom to specify dependencies. After all, GCL depends
> > intimately on GCC and binutils but we do not include a copy
> > of these in the Axiom installation. What is needed is simply
> > to document the known dependencies and to modify the Axiom
> > build to make patching GCL (and noweb) unnecessary.
> > 
> > Regarding ports to other systems, we are already doing this
> > in the case of the port to Windows.
> 
> Well, as they say, advocacy is volunteering. :-)
> 

Just another thought here.  I agree that ultimately it would be ideal
to have this image linking stage isolated and made generic for future
use with other lisps.  I just wanted to indicate that I don't think
both steps (e.g. build in Makefile rules to use external gcl and make
a generic external lisp interface) need happen at the same time.  The
first is quite easy, and if it were determined that it would provide
value, could be accomplished in short order.  I'd volunteer to commit
the necessary changes to the Makefile.pamphlets, should you wish.  It
can be argued that this is a low priority item gaining us nothing in
the near term, and I can respect this point of view.  But I fear we
will truly stretch our already meager developer resources too thin
should we simultaneously work on different compilers, at least at this
stage.  I'm just imagining in my C projects using gcc, and icc, then
the sgi compiler ....  If GCL is holding axiom back on any front, that
is another matter of course -- axiom should use the best tool for the
job.   I would greatly appreciate any reports on GCL deficiencies vis
a vis axiom should this be the case so we can address them.

Take care,

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]