This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Port to DOS


On Tue, Sep 21, 1999 at 11:48:31PM -0700, shawn wrote:
> Tim Bedding <tim@polyhedra.com> writes:
> 
> > I am thinking about porting Guile to DOS.
> > 
> > Has this been done already? If not, are there any reasons
> > why I should not attempt the port?
> 
> If it has been done, I'd like to know about it!

Kind of... I did it a long time ago with DJGPP and later
with mingwin-32. I found that mostly it is a matter of throwing
out unix stuff and cutting away things that don't work in DOS.
The guts of the language is very portable but some of the add-on
bits and bobs are not.

DJGPP actually gives quite a bit of fake unix support, as does
cygwin. Using mingwin-32 is the most difficult since it has no
signal support at all.

The main difficulty is not getting the source to compile but
getting all the support files to cooperate: gnu-make seems to
go everywhere but libtool and autoconf run really badly in DJGPP
and not at all in mingwin-32. I found it easier to hack around
the makefiles and tweak the config by hand than to do a proper
build. The cygwin system seems to handle autoconf stuff much
better because it has better support for bash scripts.

I gave up trying to keep it up to date because more and more people
are using Linux so trying to support DOS doesn't seem worthwhile.
Since I am doing numerical work, just about everyone in the field
is using some unix variant. I also get the feeling that most of the
guile team have little or no interest in DOS.

Basically, I think that a lot of users feel that stripping functions
out of the core and into linkable libraries is an essential step
that guile must take. Once this is done, the core itself will be
more portable even though some specific libraries may not.
I'm happy to see work being done on the module system (and to a
lesser extent GOOPS) because this has to get settled down before
splitting up the core will be feasible. I personally find the build
system to be a pain for porting because it sprawls through everything
and is difficult to adjust when something goes off the rails, the
main thing to be said for it is that (for the systems it does
support) it tends to work.

	- Tel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]