forwarded message from Stephen Weeks

[Stephen Weeks]

Here's Anoq's reply to my email.  I forwarded him a copy because of
the mailer problems, so he replied only to me.

> Hello Stephen!
> 
> 
> > Hi Anoq.  I had some mailer problems earlier today, so I'm not sure if
> > you got this.
> 
> No I didn't get it until now - thanks!
> 
> Stephen Weeks wrote:
> > Hi Anoq.  It's going well.  I've got most of our regression tests
> > working, and am dealing with the last few that aren't.  I decided to
> > go with Cygwin for now, because it has made the porting easier, and
> > because the person I am building the cross-compiler for wanted it.
> > Once all the infrastructure is in place in our sources, hopefully it
> > won't be too bad to target other Win32 Unix environments, like MinGW.
> > I have set stuff up so that multiple hosts can coexist simultaneously. 
> 
> Wow - cool! :) I thought Cygwin was only a native Win32 compiler
> with unix environment. I didn't know they had a crosscompiler version.
> I'm also glad to hear that there will now be at least one more person
> besides me who will be using MLton for Win32 programs ;)
> 
> > I am using the approach of having a constants file (with names) per
> > host, with the basis library making a distinction between constants
> > defined on the command line on the build machine (like MLton_safe) and
> > constants defined on the host machine (like Posix_IO_SEEK_END).  The
> > constants file is built once per host and is loaded at SML compile
> > time.  Although I haven't gotten around to self-compiling yet, I don't
> > think it will be don't think it will be necessary to make the
> > distinction between build, host, and target as gcc does, since for
> > now, MLton will be able to generate for all targets.  That is, we
> > won't compile a MLton that can only generate for a particular target.
> > So, for self-compiles we only need to distinguish between the machine
> > that MLton is building on and the machine that the executable will run
> > on (as we would for any application).
> 
> I think you're right. The only thing you would probably not be able
> to generate with this scheme is an MLton running on some weird system
> which is not able to compile MLton itself (like DOS with 640kb memory
> or an embedded system with very limited ressources?). But it would
> probably never be very useful to compile from such platforms in the
> first place :)
> 
> > Self-compiling isn't on the critical path, though, so I may not get to
> > it for a while unless its easy.
> 
> I don't need it either - so I guess it's only if you want to make
> compiling ML-programs for Windows with MLton a more common thing
> to do. I.e. such that Windows ( / non-Unix) developers can do it also :)
> 
> > I should be able to release an experimental version in two weeks or
> > so.  I'll let you know when it's ready.
> 
> Sounds really great! Thanks a lot!
> 
> But again - if there's anything I can do, let me know :)
> 
> 
> Cheers
> -- 
> http://www.HardcoreProcessing.com