Building GHC 5.02 on Solaris x86

[Simon Marlow]

> Yuck. If this isn't enough to convince people that hsc2hs is not
> an appropriate tool (at least in the context of the Prelude
> and hslibs/), than I don't know what is.
> 
> It commits to a particular platform at too early a stage -- details
> of C header files are often best left to....C source files 
> for C compilers
> to process and deal with, not Haskell. If possible, keeping your
> Haskell sources plat-indep. is a good goal to have, and I don't see
> any fundamental reasons why that can't be done here (indeed, the
> previous Prelude cbits/ setup was fairly close to achieving this).

Yes, I have to reluctantly admit this is an unfortunate, and unforseen,
consequence of having moved these libraries into Haskell+hsc2hs.  Oh
well.

> So, bringing back the solution of having manually written C wrapper
> functions which platform-independent Haskell source files will
> call out to, would be preferable (in short, avoid the use of hsc2hs
> *or any other extra tool* alltogether). I'm willing to make the
> necessary changes.

Having just looked at the code, it seems we could recover the
platform-independentness in the I/O library with just a small amount of
wrapperage: most of the offending code is in PrelPosix.hsc, with a few
#const's scattered around PrelHandle and PrelIO, and none of the
affected areas are particularly performance-critical.  

Also needing wrappers are Time, CPUTime, Directory & System.  I'd say
stop there, though - this is purely to make bootstrapping on a new OS
easier, so we only need to apply the no-tool restriction to libraries
needed by the compiler.

IOExts shouldn't be a .hsc file at all - the #defs are unnecessary and
even wrong (I think I've already turned these into inline functions in
HsLang.h in the new libraries).

Cheers,
	Simon