gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: [Axiom-developer] differences wh-sandbox andbuild-improv


From: Camm Maguire
Subject: [Gcl-devel] Re: [Axiom-developer] differences wh-sandbox andbuild-improvements
Date: 20 Apr 2007 12:14:43 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Bill Page" <address@hidden> writes:

> On April 18, 2007 6:00 AM Waldek Hebisch wrote:
> > 
> > Bill Page wrote:
> > > Why not? It is not necessary to build gcl as part of the Axiom
> > > build - just install the windows binary for gcl, like other
> > > users Windows do.
> > >
> > 
> > Is there a binary version of gcl suitable for Axiom developement?
> > The latest binary I see is 2.6.6, but AFAIK with 2.6.6 we are
> > getting errors which vanish if we use 2.6.7 or 2.6.8.
> 
> You are right and what I wrote above is wrong. Gaby also has
> pointed out that it is not currently realistic to depend on the
> GCL binaries on Windows for Axiom development.
> 
> As far as I can tell no one has posted any binaries for GCL on
> windows newer than
> 
>   gcl_2.6.6.mingw32_cltl1_japi_20050210.exe 22-Mar-2005
> 
> at
> 
>   http://ftp.gnu.org/gnu/gcl/binaries/stable
> 
> And gcl-2.6.8pre is still a "pre-release". I guess the gcl
> project is also critally lacking in resources. If it would be
> helpful I could certainly upload a windows binary of this
> pre-release to the Axiom Wiki web site. But I am discouraged
> also by Gaby's observation that there does not seem to be much
> interest in development of the Windows versions of GCL or
> Axiom. :-(
> 

Thanks so much for this update.  GCL development, like most open
source projects run by volunteers, usually proceeds in bursts, most
frequently during the summer months.  But I think it is also true, as
we've discussed personally in the past, that the community dynamics of
Windows computer users are by in large quite different from BSD/Linux
users, in that relatively speaking there are far fewer people
interested in actually contributing work than in simply downloading
the work done by others.  Mike Thomas was of course the heroic
exception in this regard, and his determination of the superiority of
the mingw environment vis a vis the cygwin environment coupled with
his more than ample contributions of time and skill have given us the
mingw system we have today.  I do think we need to discuss the way
forward, for unless we find his equivalent somewhere, it can be argued
that it would be better for us to migrate to a system that can be well
emulated and/or remotely accessed under Linux using familiar tools,
even if those are deficient in other regards with respect to customary
Windows usage.

>From my own perspective, I feel most able to support (in descending
order) Linux, BSD, Solaris, MacOSX, and lastly mingw, and alas it is
likely to remain that way.  We therefore are first in needs of a
Windows porter, and next a MacOSX porter.  I feel that GCL has also
accumulated a certain degree of mingw experimental code which no one
uses to my understanding and should be removed on conceptual grounds.
I.e. japi and anything related to java, the separate windows main
routines, and perhaps some alternative tk stuff if memory serves.  I
think we need to consolidate around unix concepts to the degree
possible given our resources, and provide minimal well centralized
emulations where required, e.g. sbrk.  This means in all likelihood
fork(), unix sockets, etc., which to my limited understanding point
more in the direction of cygwin than mingw.  (2.7.0 has parallel
processing primitives based on fork.  pargcl, an mpi extension, is
also likely to be built by default in 2.7 and higher.  This latter
facility of course just requires a uniform external mpi interface
which I hope we can avoid including with the gcl source as gmp and bfd
are done now.) I don't think we should discontinue mingw so much as
investigate a cygwin alternative which, if proven over time to be
accessible within unix and adequate from the user's perspective, might
eventually become the windows port of choice.

This said, I will turn 180 degrees if anyone would like to step
forward and fill Mike Thomas' shoes. 

Finally, I'm not even familiar with the windows package format
concept, so if anyone would like a binary posted, we need a
volunteer.  I'd be quite happy to provide access to any qualified
individual with interest.

> > 
> > Also, can one install gcl without affecting existing Mingw
> > installation (the gcl readme claims that on Windows gcl
> > need a specific, rather old Mingw version -- for me
> > downgrading Mingw is not an option)?
> > 
> 
> MinGW is required in order to compile Lisp to object code and
> of course to compile the Lisp output of the SPAD compiler in
> Axiom. Unlike Linux, it is not correct to assume that a C
> compiler is available in the basic window installation. The
> existing binary installer that I prepared for Axiom on Windows
> includes the necessary parts of MinGW to permit GCL and Axiom
> to compile object code. I think a similar binary installer
> for GCL should include these same parts of MinGW so that the
> GCL installation will be complete and fully functional.
> 

How big will this be?  Who can tell me exactly what that means in
terms of files shipped?

Take care,

> Regards,
> Bill Page.
> 
> 
> 
> 
> 

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