64-bit windows version?

[Simon Marlow]

Peter Tanski wrote:

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

Surely this isn't hard?

ifeq "$(TargetOS)" "windows"
osuf=obj
else
osuf=o
endif

and then use $(osuf) wherever necessary.

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

I don't understand the last sentence - what paths?  Perhaps I wasn't clear here: 
I'm talking about the foreign calls made by the base package and the other core 
packages; we can't call any functions provided by the mingw C runtime, we can 
only call Win32 functions.  Similarly for the RTS.  I have no idea how much 
needs to change here, but I hope not much.

>>  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,
	Simon