64-bit windows version?

[Peter Tanski]

On Jun 22, 2007, at 7:03 AM, Simon Marlow wrote:
> In fact, to build a source distribution on Windows, there are only  
> 3 dependencies:  GHC, Mingw and (either MSYS or Cygwin).
>
> To build from darcs, you also need: darcs, Happy, and Alex.  To  
> build docs, you also need Haddock.  To run the testsuite you need  
> Python.

True, Mingw does come standard with perl and a version of flex.   
There are Windows-native versions of Perl and flex available (i.e.,  
ActivePerl).  Now you are familiar with Mingw.  Imagine being a  
standard Windows programmer, trying to choose which version of Mingw  
to download--some are minimal installations--and going over the build  
requirements: perl, flex, happy, alex and, haddock are listed.  That  
is quite a bit of preparation.  There are minimal-effort ways to go  
about this (I will look into updating the wiki.)

> > Whatever the end result is, GHC must be able to operate without  
> Mingw
> > and the GNU toolset.
>
> That's the whole point of doing the port!

For running GHC--how about being able to build a new version of GHC  
from source?

>  1. modify GHC so that:
>     a) it can invoke CL instead of gcc to compile C files

Mostly done (not completely tested).

>     b) its native code generator can be used to create native .obj  
> files,
>        I think you kept the syntax the same and used YASM, the other
>        alternative is to generate Intel/MS syntax and use MASM.

This is as easy as simply using Yasm--also mostly done (not  
completely tested).  By the way, by "testing" I mean doing more than  
a simple -optc... -optc... -optl... addition to the command line,  
although an initial build using a current mingw version of GHC may  
certainly do this.

>     c) it can link a binary using the MS linker
>  2. modify Cabal so that it can use this GHC, and MS tools
>  3. modify the build system where necessary to know about .obj .lib  
> etc.

A bit invasive (it involves modifying the make rules so they take an  
object-suffix variable).  Instead of the current suffix.mk:

$(odir_)%.$(way_)o : %.hc

it should be:

$(odir_)%.$(way_)$(obj_sfx) : %.hc

or some such.  This may affect other builds, especially if for some  
reason autoconf can't determine the object-suffix for a platform,  
which is one reason I suggested a platform-specific settings file.  I  
could handle this by having autoconf set the target variable, put all  
the windows-specific settings in a "settings.mk" file (including a  
suffix.mk copy) and have make include that file.

>  4. modify the core packages to use Win32 calls only (no mingw)

That is where a lot of preparation is going.  This is *much* harder  
to do from mingw than from VS tools since you have to set up all the  
paths manually.

>  5. Use the stage 1 GHC to compile the RTS and libraries
>  6. Build a stage 2 compiler: it will be a native binary
>  7. Build a binary distribution

I told Torkil I would have a version of the replacement library  
available for him as soon as possible.  I'll shut up now.  It looks  
like a long weekend.

Cheers,
Pete