I built darcs for win32 recently and it was much more difficult than
it should be.  Probably most of the blame goes to ghc-6.8.2 binary
release for win32.  Half of the effort is getting the zlib prereq
working.

Previously to build zlib for win32 ghc I did the following:
http://www.haskell.org/pipermail/haskell-cafe/2007-March/023059.html

However, now, the gcc binary for ghc-6.8.2 does not work as well as
I would like which requires a bit more effort:

- It did not automatically add mingw headers during compilation, and
   to fix this I had to force some extra flags.  I built a shell script
   "xcc":

   #!/bin/sh
   GHC=/ghc/ghc-6.8.2
   PATH=/c$GHC/gcc-lib:$PATH
   export PATH
   /c$GHC/gcc -I $GHC/include -I $GHC/include/mingw \
              -I $GHC/gcc-lib/include -L $GHC/gcc-lib "$@"

- During linking it did not find crt2.o and adding it to PATH and
   -L did not help, so I just copied wholesale all of
   /c/ghc/ghc-6.8.2/gcc-lib into my zlib source directory.

- At this point I was able to build with:
   CC=./xcc ./configure --prefix=/c/ghc/ghc-6.8.2 \
                        --libdir=/c/ghc/ghc-6.8.2
   make
   make install

Why is the gcc in ghc's directory so non-functional?

Ok, so with zlib (the C library) installed, the zlib haskell package
installs properly.  Dependency resolved.

Next, to build darcs I had to configure it without libcurl support
(or alternately spend time chasing down that dep, pass for now). 
Using cygwin I ran "./configure" which falsely uses the cygwin gcc
for configuration checks, but since gcc is never used directly during
the compilation process, that doesn't matter that much.  I could have
tried the "xcc" trick here again, but didn't bother.  I ran into
two problems during the build:

- -Werror is specified in the GNUMakefile and there are many warnings.
   I just removed -Werror for now.

- During linking it was not able to resolve "SleepEx" from
   src/win32/System/Posix.hs.  I could not figure out what is going
   on here.  I tried adding "-lkernel32" and "-L /ghc/ghc-6.8.2/gcc-lib
   -Lkernel32" to the Makefile and it still did not work even though
   /ghc/ghc-6.8.2/gcc-lib/libkernel32.a has SleepEx@8 defined(!)
   Finally I bit the bullet and hacked around this by noticing that
   mingw headers have _sleep() defined.  I replaced the code in Posix.hs
   with:

   foreign import ccall "_sleep" c_sleep :: CULong -> IO ()

   sleep :: Integer -> IO CInt
   sleep n = c_sleep (fromIntegral n) >> return (toEnum $ fromIntegral n)

At this point darcs builds and the binary seems to work (so far).
I don't know the implication of my sleep hack (which doesn't return
the actual time slept).

Here's a small test program which uses FFI to SleepEx which I was
not able to get working with win32 ghc-6.8.2.

------
{-# OPTIONS -fglasgow-exts -fffi #-}
module Main where
import Foreign.C.Types

foreign import ccall "SleepEx" c_SleepEx :: CUInt -> CInt -> IO CInt

main = do
     putStrLn "start"
     n <- c_SleepEx (2*1000) 1
     print n
-------

So, what is going on with ghc-6.8.2?  Why is the gcc so hard to use
now?  Why can't I get FFI working with standard win32 functions?
Why aren't there prebuilt win32 darcs binaries anymore?

Tim Newsham
http://www.thenewsh.com/~newsham/

Zooko: whatever happened to the darcs2 binaries for Windows?

Tim:

I've been working on a recipe for building darcs on Windows:
  http://wiki.darcs.net/index.html/BuildingUnderWindows

Perhaps you'd like to flesh it out.  Note that I did not have much trouble with
the zlib prereq.  I did discover that running darcs in cmd.exe (instead of under
msys sh.exe), it would complain about zlib1.dll.  But that was "easily"
rectified by copying it from the libcurl distribution.

I'm still fighting with libcurl myself.  I've gotten to the point where it
compiles against my self-built libcurl, but when running darcs, it complains
that "There is no libcurl".  Will update you on that later.

To be honest, I didn't understand the rest of your mail (maybe underqualified,
maybe just need to read it more slowly), but I will re-read it later.  I guess
one question to ask would be "why would you want to add the mingw headers during
compilation in the first place?"

Wait a sec: why are you trying to build the haskell zlib?  We don't need it.  We
just use the C lib.

Also, I've resolved my libcurl issues (with a small patch for
--with-static-libs), so I do know it is possible to build under MSYS with
minimal pain (hoops, yes, pain no...)

What happened to my Windows binaries?

I got frustrated with (a) darcs build on Windows being a "manual" rather than
"automated" process, and (b) my attempt to automate that process running aground
on autoconf/configure being a tool that works well for Unix, not Windows, and C,
not Haskell.

I intend to try again at some point, probably by starting with Gwern's Cabal
patches for darcs so that I won't have to touch autoconf again.

Sorry, I misunderstood the question "What happened to my Windows binaries?".

I thought you meant: why didn't I finish my project of getting the buildbots to
automatically produce new Windows binaries.

What you were probably asking is: Why do I get 404 Not Found when I try to fetch
the 2.0 binaries?

I just now noticed that latter problem, and I put them back.  That was a
mistake.  Sorry!

Elsewhere in the bug tracker we've documented that GHC 6.8.2 has broken
calculations of "mtimes" which can slow down some operations by 600%. 

Is there any better luck trying with a newer release of GHC on Windows? Even
just 6.8.3?

The build system has been complete changed, from being based on autoconf/GNUmake 
to being based on the Haskell cabal build tool.

Petr has done some work trying to install darcs on Windows lately.  He reported
on IRC that this is now super easy with the Haskell Platform beta: just install
the platform and cabal install.

I say we resolve this.