gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: GCL and Ubuntu


From: Camm Maguire
Subject: [Gcl-devel] Re: GCL and Ubuntu
Date: 05 Jan 2006 13:23:19 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!  Am happy to announce that I've restored xgcl-2 in stable
release candidate version 2.6.8pre (in cvs) (and soon in cvs head):

export CVSROOT=:pserver:address@hidden:/sources/gcl
cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
cd gcl-2.6.8pre && ./configure && make && make xgcl

or 

cd gcl-2.6.8pre && ./configure && make && cd xgcl-2 && make

I've checked the demos, and they look good.  I would like to integrate
this as an autoloadable module built by default in the next release if
possible.  There remains a bit of work, the hardest part of which is
deciding exactly how to do this :-).

A few issues:

1) X10.h is no longer supported by X.  I've managed to find an old
   version, and have inlined the header into general-c.c, but it would
   be perhaps more proper to replace the obsolete X10 interface with
   an X11 equivalent.  This is beyond my immediate expertise.

2) It still remains to get the build working against the ansi image.
   I suggest here that we abandon the older :system-p based
   compilation system in favor of the equivalent but more portable
   'compiler::link interface.  This will free us from any direct
   reference to a particular saved image (either traditional or ansi),
   and need only be run (on most architectures) on the explicitly
   compiled C files, leaving the remaining .lsp files compilable,
   loadable, and dumpable without the :system-p flag.  Actually, the C
   files themselves could be included via (clines "....") into
   compilable and loadable lisp.  This needs more thought --
   suggestions are most welcome.

3) There is a very large set of imports in xgcl-2/gcl_imports.lsp.  If
   this does not bother one for generic use, one approach would be to
   select a few of these, such as 'draw, 'pcalc, 'menu, and perhaps a
   few others, which would autoload the xgcl "module" together with
   the imports file, and output a simple help text to the screen.  Bob
   Boyer has previously expressed his opinion that autoloading is
   problematic and non-portable.  If this is the consensus, then we
   should pre-load the compiled files into all images, and perhaps
   only autoload the imports file, or perhaps rather export the
   symbols from 'xlib instead and instruct the user to (use-package
   'xlib).  I hesitate to pollute the default user package namespace
   with so many specific symbols.

4) Documentation -- I suppose the dwdoc.tex should be converted to
   info format and included in or along side of gcl-si.texi.  Perhaps
   also the Xakcl-paper, though this is clearly more work.

More later,

"Gordon Shaw Novak" <address@hidden> writes:

> I tested the existing versions of xgcl and gcl under ubuntu
> and they seem to work.  Therefore, I think we can migrate to
> ubuntu without losing the ability to use gcl.
> 
> Of course, ultimately we need to be able to compile.
> BTW, I still can't get xgcl to compile any more.
> It may be something fairly simple.
> /stage/public/share/src/gcl-2.6.7/xgcl-2/make.script shows where
> it messed up.
> 
> Best regards, Gordon
> 
> 
> 

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