64-bit windows version?
simonmarhaskell at gmail.com
Fri Jun 22 11:42:54 EDT 2007
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"
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
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.
More information about the Glasgow-haskell-users