64-bit windows version?

[Simon Marlow]

Peter Tanski wrote:

> I keep on referring to this as temporary because there are two different 
> builds here:
> (1) the build using the old mingw-GHC, without option support for CL; and,
> (2) the build using the new Windows-native GHC.

Yes.  And what I'm suggesting is the following - what I've been suggesting all 
along, but we keep getting sidetracked into sub-discussions:

  - the initial bootstrap is done by hand. (your (1) above).  All you need to
    do is build stage 1 using an existing mingw-GHC.  The stage 1 that you
    build will be capable of creating native objects and binaries.  Any hacks
    you have to apply to do this part are certainly temporary.

  - we adapt the current build system to use the native GHC.  I really don't
    think this is hard, and it's way quicker than replacing significant chunks
    of the build system, as you seem to be suggesting.

So the result is a build system that can build a win-native GHC using another 
win-native GHC, but not necessarily build a win-native GHC using a mingw GHC.


I'm not against VS in particular - I'm against duplication.  Build systems rot 
quickly.  By all means discuss a wonderful replacement for the current build 
system -- I'm aware that the current system is far from perfect -- but I'm not 
at all convinced that it is a necessity for building win-native GHC.

I could be wrong.  If I am wrong, then constructing a convincing argument might 
be difficult, because it's a matter of details - the cumulative weight of things 
you have to hack is too great.  So go ahead and use VS or whatever; but please 
think very carefully before doing so, because it's not cost-free.  We're not 
going to drop the mingw port of GHC, and it's hard to keep everything working as 
it is.  We'll have to import new hackers who understand VS builds, because none 
of the current GHC maintainers do!


>> Use GHC as your C compiler, i.e. don't invoke CL directory from make, 
>> and add the INCLUDE/LIB directories to the RTS's package.conf.
> 
> Certainly doable but it does present a conundrum: for the old GHC 
> (without builtin cl-support) the order for compilation seems to be:
> <compile/link command> <compile/link flags> <output> <source/object 
> files> <other flags>
> while for cl running link.exe or link.exe, it is better to put all the 
> files at the end of the command line:
> <compile/link command> <compile/link flags> <output> <other flags> 
> <source/object files>

Why is that a "conundrum"?  GHC can invoke CL with the arguments in whatever 
order it likes.  Sorry, but this just seems like a trivial detail to me.

> It also adds one more layer of indirection a that delicate stage.

huh?  GHC already invokes gcc, you need to change it to invoke CL anyway.

Cheers,
	Simon