[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: [Axiom-developer] New design for Axiom web site
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Re: [Axiom-developer] New design for Axiom web site |
Date: |
01 Oct 2003 11:28:39 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings! You guys type so fast! I'm going to try to be brief to
catch up...
1) Tim, whatever you feel is best for axiom is best in my book too.
All the foregoing are offered as suggestions only.
2) (pros and cons of an external gcl build discussed in a separate
reply to your other post)
Tim Daly <address@hidden> writes:
> > Having some kind of useful mechanism of adding extensions seems to be
> > a focal point?
>
> I suppose. The key problem I've had with adding extensions to gcl
> has been system libraries, not gcl itself. The first attempt at
> system building was on Redhat 7.3 and required an XFree library
> which was not part of the standard build. I had included the rpm
> as part of the CVS zips but was convinced that this was, well,
> lets just say, ummm, inelegant :-)
>
3) non-lisp C extension modules and libraries can now be linked into
an externally installed GCL from lisp via compiler::link.
4) An older faslink method can be reenabled if desired with likely
minimal work.
5) Build dependencies as referred to above are handled automatically
in most modern distributions. Look at the Build-Depends: line in
the debian/control file of the GCL source. There is an analogous
line in the Debian axiom package. IMHO, the vast majority of axiom
users will never compile it, but install it and its runtime
dependencies automatically with a single command. The next largest
group will compile it, but will do so by downloading the source and
automatically installing its build-dependencies also with a single
command. So I think axiom need not fear having external
dependencies as long as they are clearly specified, knowing that
only the 'experts' will ever have to take care of ensuring their
presence when needed. I think the 'inelegance' you felt above goes
right to the heart of the modular software design we're all
striving towards, and might arguably pertain to a subsidiary lisp
build as well.
> The Mandrake install is giving me similar library issues as is
> the iMac. I tried getting the latest CVS of GCL but it still
> doesn't build. How did you get the Mac build to succeed?
>
6) When accessing CVS, please use the 'stable' branch, by adding '-r
Version_2_6_1' after the 'checkout' command word. This is
explained on our temporary distribution site:
http://people.debian.org/~camm/gcl
We've just put this together in response to ftp.gnu.org's
inaccessibility. And David, thanks for the pointer about the file
restorations there (!). But alas, the machine I used to access the
tree is still unavailable, and I cannot get responses from the ftp
managers for a new account on whatever new machine is involved.
7) Has Aurelian been in touch with you?
8) If you can provide remote ssh access to your imac, I'll get GCL
running for you.
> Dynamically adding extensions will mean that the lisp loader
> will have to automatically find and link new system libraries.
> That's quite a large task.
9) If the system libraries are specified, (modern distros use a
'soname' to denote compatible shared libraries, so this should be
in the specification, but not the minor point release/bug fix
release number, i.e. libfoo.so.2, not libfoo.so.2.3), GCL can build
this link in already via compiler::link. This method requires a
restart of the lisp, whereas if we were to resurrect the faslink
method, a restart would not be necessary.
>
> > The above will need to find a saved_gcl, no? (I'll fix the FreeBSD port
> > to add this to the installed bits if so).
>
> The above essentially copies saved_gcl to obj/linux/bin/lisp.
> In some hopeful future you should just be able to find the lisp
> on the path.
>
10) If you just link the external saved_gcl to obj/linux/bin/lisp, it
won't have your extensions compiled in. You will get a saved_gcl
with these extensions compiled in if you use compiler::link as
outlined in the long email.
> > The FreeBSD port infrastructure takes care of the details, like installing
> > GCL if its not already there.
>
> Can you point me to the docs on this? How does this magic happen?
>
11) At least for Debian, you can look at pbuilder and apt-src.
> > Did you get his long email
>
> Yes, this morning. (Last night was my anniversary so I was kinda
> lame about reading email). I'll study it in more detail.
>
11) Happy anniversary! Don't you dare even think about this stuff on
such a blissful occasion :-).
Take care,
> Tim
> address@hidden
>
>
>
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah