axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] [build-improvements] Update to recentGCL-2.6.8pre


From: root
Subject: Re: [Axiom-developer] [build-improvements] Update to recentGCL-2.6.8pre CVS
Date: Sun, 29 Oct 2006 16:19:21 -0500

> Let me take this opportunity to raise again the question of
> whether it still makes sense to store the gcl source as a
> tarball in the axiom source tree. If we are going to keep a
> copy of gcl around just in case we have to build it in order
> to install axiom, then why don't we just make it a real part
> of the axiom source tree. Why zip it? This just makes things
> more complicated than it needs to be (and makes some people
> at Google nervous :-).

Let me take this opportunity to raise again the answer to the question.

Axiom is not trying to maintain a clone of GCL. The idea is to make
sure that Axiom works on a given platform with a given snapshot of GCL.
Adding it to the source tree as individual files is a waste of time.
Indeed, it might extend the SVN checkout by another half-hour if my
current experience is any measure.

At the present time we need to maintain two different snapshots of GCL,
one for general linux (gcl-2.6.8pre2) and one for fedora 5 (gcl-2.6.8pre).
These are incompatible. Worse yet, these two versions are not explicitly
tagged in the GCL CVS so we can't automatically fetch them. 

Eventually this difference will disappear but it needs to exist for now.

I'm not sure how Gaby will handle different patch sets to GCL that need
to be applied for different platforms. I'm awaiting that result.

In the fullness of time I expect that we will have an ANSI common lisp 
version of Axiom and will be again able to run on various platforms
using only standard common lisp primitives. However that goal may
require a restructuring of the Axiom build process. Eventually a GCL
special version will go away but not in the near future.

Indeed, an ASDF based version of Axiom will completely enclose the
whole issue into a proper lisp build framework and the whole build
process can disappear.




As for making Google nervous, this again raises the issue of forming
policy around the tools. It is a reprise of the noweb discussion.
What we want to do should be decided independent of the tool.

Google owns more online storage space than any single company in
history.  The idea of a 20M file should not make them cringe. I have
20M+ powerpoint presentations for work. If they won't host it then
I will personally pay for additional storage on axiom-developer.org
and solve the problem.




And since advocacy is volunteering we're awaiting the code which
implements your proposed alternate solution. Note that apt-get and
similar tools are not available for all platforms.  Even if you have
apt-get you can't install the tools without being root in most cases
because you are required to update minor things like glibc. In fact we
had this problem with latex and the sourceforge compile farm.  Do you
propose writing code to automate the CVS checkouts for GCL, Arch, and
noweb? If not, how do you plan to implement this?



Since you've raised this question so frequently I'll add it as a FAQ.

t





reply via email to

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