Re: building ghc from source

> Yes -- but hslibs/win32 should be fixed, or else nuked in favour of
> libraries/win32, which Alastair is working on.
>
> Alastair: what's the story on win32 in hslibs/ or libraries/?

I'd hoped to have the changeover done by now but I don't and won't in time so, 
for now, hslibs/win32 is the one to go with for ghc 6.0.

[In particular, I haven't tried building libraries/win32 ever.]

My plan is that win32, xlib, greencard, libgreencard (i.e., StdDIS.{gc,hs}), 
HGL/win32 and HGL/xlib should all be separate packages from each other and 
from ghc.  I am hoping to trickle these packages out over the next few weeks 
and my thought is that future releases would happen independently of each 
other, of ghc, of hugs, etc.

But, BIG PROBLEM:

From this email thread, it seems that building GHC depends on building win32.
This means:

1) win32 has to be built in non-standalone mode - i.e., when building a ghc 
release.
2) win32 has to be distributed by you guys (because other things you 
distribute depend on it)
3) If I distribute win32, it will clash with the copy you distribute and 
depend upon.

The problem is a circular dependency so we can solve it in one of two ways:

1) Break the packages into smaller pieces.
    You would distribute one piece with ghc and I'd distribute the other.
2) Replicate the bit of win32 that you use.
    That is, you find the few functions that you need and write raw ffi 
    code to access them.

--
Alastair