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
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
