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