RE: [Axiom-developer] [build-improvements] Update torecentGCL-2.6.8pre CVS

[Bill Page]

On October 29, 2006 4:19 PM Tim Daly wrote:

> 
>Bill Page wrote: 
> > 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.
>

Tim, you have never provided a satisfactory answer.
 
> Axiom is not trying to maintain a clone of GCL.

Agreed.

> The idea is to make sure that Axiom works on a given platform
> with a given snapshot of GCL.

Why should Axiom care about a particular snapshot of GCL?
We don't care about particular snapshots of gcc or other
build dependencies.
 
> Adding it to the source tree as individual files is a waste
> of time.

That is not true. Having to create and uncompress a tarball is
what is the waste of time. More over all of the source code
control systems that we are using work much better with actual
source files. Storing large binary blobs defeats the mechanisms
that are built in to these systems for efficiently handling source
code as source code (text files).

> Indeed, it might extend the SVN checkout by another half-hour
> if my current experience is any measure.

Your experience with SVN is unique and your conclusion is
nonsense. If anything, one of the causes of poor performance
is precisely because we are trying to store and copy objects
that are over 20 Mbytes in size. This is a large block of data
to move as one transaction. The compression methods that are
built into the source code control systems do not work very
well when applied to previously compressed binary data and in
some cases can even increase the amount of data that must be
transmitted.

> 
> 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).

If there are problems installing gcl on a particular platform
then that should be addressed upstream by the maintainer of gcl,
not axiom. To do otherwise is to deprive other users of gcl
from the benefit of solving these problems. As you know, the
developer (Camm) is very responsive to problems that are
reported to him.

> These are incompatible. Worse yet, these two versions are not 
> explicitly tagged in the GCL CVS so we can't automatically
> fetch them. 

The reason you have tied yourself into this knot is because you
are trying to use pre-released versions of gcl. Pre-release
means pre-release and subject to change. There is no way that
you should be using such versions in Axiom Gold.

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

I don't see why. If you report the problem that you have building
gcl on fedora 5 to Camm, I am sure the problem can be resolved
quickly and then you can incorporate an actual released version
of gcl-2.6.8 when it is available.
 
> 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.

There is no need to handle patch sets against GCL.

> 
> 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.

An ANSI common lisp version of Axiom has nothing to do
with this issue.

> 
> 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.
> 

I simply don't believe this statement at all.
 
> 
> 
> 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.

My original comment also applies to noweb. I don't see any
reason to keep it as a compressed zip file in the axiom source
tree. If we decide that we really do need a copy of noweb -
for convenience or whatever, then it should be stored some
source subdirectory just like gcl.

I don't understand what you mean by "independent of the tool".
Axiom is dependent on the tools needed to build axiom - that
is a fact.

> 
> 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.
> 

I agree that Google is being unreasonable and I don't understand
why. But the reason to continue to "court" Google has nothing to
do with the resource that they may or may not make available - it
is simply because have a project present on Google Code gives it
more credibility and visibility just by association with Google.

We can certainly host the Axiom SVN repository on axiom-developer,
in fact we already have several versions of the repository there
already. The problem is only finding time to update the version
of Apache that is used there so that we can install the SVN
server software. I'll return to this real soon now, unless some
one has time to help sooner.

> 
> And since advocacy is volunteering we're awaiting the code which
> implements your proposed alternate solution.

That is not a problem. I am only talking about the build-improvements
version of Axiom. It only has one version of Axiom in the zips
directory and no patches. If gcl is previously installed on a system
then it doesn't't need the version in Axiom as all.

All I am suggesting is in build-improvements, scrap the zips
directory and put the source for both gcl and noweb directly in
the source tree where they can be found if needed.

> 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.

This is an issue that any linux developer has to solve in order
to setup a proper build environment. For most people this is not
a problem.

> Do you propose writing code to automate the CVS checkouts for
> GCL, Arch, and noweb? If not, how do you plan to implement this?
>

No. Implement what?
 
> 
> Since you've raised this question so frequently I'll add it as
> a FAQ.
> 

I hope you can think of a reasonable answer to accompany the
question. ;)

Regards,
Bill Page.