Win-GHC with GnuWin32 toolset--Mingw32 replacement

Simon Marlow simonmarhaskell at gmail.com
Mon Jan 8 10:39:27 EST 2007


Peter Tanski wrote:
> Part of the problem when attempting to use MS tools to build GHC is  the 
> difference between Mingw32 library names (lib*.a, .so), which CL,  LIB, 
> etc. do not recognise.  The other part of the problem is the  Mingw 
> toolset, notably AutoConf, AutoMake and Make, which do not  understand CL.

1. we don't use automake.
2. make is independent of the C compiler, except for its default suffix rules,
    which we don't use.
3. that leaves autoconf.  Sure autoconf does a bunch of tests using gcc, but
    I guess most of these aren't problematic because we either ignore the
    results (using #ifdef mingw instead), or the results will be the same
    for both mingw gcc and CL.

So I'm not sure we need a heavyweight solution here.  I had imagined that we
would continue to use MSYS or Cygwin as the build platform, but GHC itself would
invoke CL instead of gcc.

Certainly some build system changes are required - as you say, the filename
conventions will be different (.o vs. .obj, .lib vs. .a, etc.).  But if possible
let's not require a whole new toolset to build GHC.  If that happens, it's a
problem because it adds another testing dimension.

Cheers,
	Simon



More information about the Cvs-ghc mailing list