gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: gcl


From: Camm Maguire
Subject: [Gcl-devel] Re: gcl
Date: 16 Dec 2001 12:05:03 -0500

Dan Stanger <address@hidden> writes:

> In the directory unixport, there is a program that gets run as a seperate
> executable (I think)
> called rsym.exe.  There a versions for different operating systems.  What it 
> does
> (I think)
> is to create a file of symbols for a module so it can be loaded.  I tried 
> running
> it once, and it
> created a file, while I did not examine the contents closely, it seems to 
> contain
> symbols in it.
> 

Thanks!  I see it now.

> Re cygwin, I was thinking about ifdefs in the code.  There a some places where
> UNIX_CYGWIN
> would be correct, others maybe not.  When Dr. Schelter built this for 
> windows, he
> used the
> mingw enviornment, which is a stripped down version of cygwin (I think).  
> However,
> to get this running, I think we should only use cygwin, and not worry about 
> mingw.
> cygwin is close enough to a unix enviornment so that xfree86 works.
> 

Agreed, cygwin is the way to go for our porting efforts.  Again, it is
going to be most helpful to get specific recommendations from people
with these boxes at hand to test on.  In addition to yourself, David
Billinghurst has volunteered to help here.

> Regarding testing, early versions of clisp were CLtL1, and there were 
> extensive
> tests for it.
> 

Great!  I'll start looking, but anyone have a URL?

> Anyway, I have downloaed the cvs last night, and will try to build it and see 
> what
> breaks.
> 

Thanks again for your report!

> Dan
> 
> Camm Maguire wrote:
> 
> > Greetings, and thanks for the clarification.  I'm going to log this to
> > the task page at savannah.  Sounds like a good suggestion to be sure,
> > but it should take some time I'd think to check the defines, if there
> > are many, to make sure that they are being applied correctly.  For
> > example, WIndOWSNT && !(UNIX_CYGWIN) seems to indicate that both can
> > be detected in the same build -- do you not envision them as mutually
> > exclusive, at least for the purposes of the build?  If not, we need to
> > understand what the former and latter are separately meant to specify.
> > Also, and please forgive my ignorance here -- what are you referring
> > to by the 'rsym' stuff?
> >
> > I agree completely that we ought to take a close look at how clisp
> > does this.  With some helpful feedback and testing from people like
> > you with these types of machines at hand, we ought to be able to get
> > something at least rudimentarily working soon.
> >
> > address@hidden writes:
> >
> > > I have a web site www.diac.com/~dxs and I will create a link to
> > > the build there, I should be able to do this by monday.  You asked
> > > how clisp handles cygwin, it creates a define called UNIX_CYGWIN if
> > > (i think) __CYGWIN__ is defined.  gcl uses WINDOWSNT (i think) to
> > > determine the enviornment, which may work for mingw.  What I think
> > > should be done is to add UNIX_CYGWIN to those places where UNIX is
> > > defined and where it it appropriate, and maybe change WINDOWSNT to
> > > WINDOWSNT && !(UNIX_CYGWIN).  It looks like the rsym stuff works,
> > > at least the exe creates a file that has symbols in it.
> > > The configure at least needs to change to detect cygwin, like clisp does.
> > > BTW, Bruno Haible did a great job making clisp compile on multiple 
> > > platforms,
> > > and his ideas would be good to integrate into gcl.
> > > Dan
> > >
> > >
> >
> > --
> > Camm Maguire                                            address@hidden
> > ==========================================================================
> > "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> 
> 
> 

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