64-bit windows version?

[Simon Marlow]

Peter Tanski wrote:

> Maybe this depends on the type of convenience you want to offer 
> GHC-developers.  With the autoconf system they are required (for 
> Windows) to download and install: Mingw, perl, python (for the 
> testsuite), flex, happy, alex and some others I can't remember right 
> now.  Oh yeah, GMP.

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.

>  When I did that, autoconf gave me the convenience 
> of having those programs somewhere in my $PATH and if autoconf found 
> them I was good to go.  The way I would change things would not be so 
> different, except that the developer would have to set up the build 
> environment: run from under Mingw, etc.  The benefit would be that 
> instead of testing all the extra things autoconf tests for--path 
> separator, shell variables, big/little endian, the type of ld and the 
> commands to execute compile--those would be hard-wired because the 
> system is known.  When things break down you don't have to search 
> through the long lines of output because you know what the initial 
> settings are and can even rely on them to help debug Make.
 > This is the
> way it is done for several systems: NextStep (now Apple) project 
> makefiles, Jam, and many of the recent build systems, including CMake, 
> Scons and WAF.

Ok, you clearly have looked at a lot more build systems than I have.  So you 
think there's a shift from autoconf-style "figure out the configuration by 
running tests" to having a database of configuration settings for various 
platforms?  I'm surprised - I thought conventional wisdom was that you should 
write your build system to be as independent as possible from the name of the 
build platform, so that the system is less sensitive to changes in its 
environment, and easier to port.  I can see how wiring-in the parameters can 
make the system more concrete, transparent and predictable, and perhaps that 
makes it easier to manage.  It's hard to predict whether this would improve our 
situation without actually doing it, though - it all comes down to the details.

On the other hand, we do hard-wire a lot of knowledge about Windows rather than 
autoconfing it.  This works because Windows is a fixed point; in contrast every 
Linux system is different in various ways.  So I guess I don't find it 
problematic to wire-in what happens on Windows, but I do try to avoid it where 
possible.


Getting back to the Windows native port, I'm pretty sure you're making more of a 
meal of this than necessary.  There's no need to port via HC files, unless I'm 
missing something.

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

However, what I'm saying is that we can continue to use Cygwin as a set of tools 
for doing the build.  I don't see any problems with this (except that Cygwin is 
slow and clunky), and it keeps the changes to the current system to a minimum, 
and means we can continue to share the build system with Posixy systems.  Here's 
the plan I had in mind:

  1. modify GHC so that:
     a) it can invoke CL instead of gcc to compile C files
     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.
     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.
  4. modify the core packages to use Win32 calls only (no mingw)
  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

Regarding autoconf, for the time being, just supply ready-made output files 
(mk/config.h, libraries/base/include/HsBaseConfig.h, etc.).

Cheers,
	Simon