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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
