gcl-devel
[Top][All Lists]
Advanced

[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




reply via email to

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