On Jan 8, 2007, at 10:39 AM, Simon Marlow wrote:
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.

Thanks! That's good news!

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.

We shouldn't. I have been following that strategy, especially since the alternative seemed to be a hc-build which would require much more configuration. There are a great many posix-library dependencies in there I have to work through; profiling may not be available initially.

For the next step, the move to DLLs produced by NativeGen, GHC uses what Windows calls the __cdecl calling convention (caller performs stack cleanup, underscore '_' prepended to function name), while to my knowledge DLLs require the __stdcall calling convention (callee performs stack cleanup, same '_' prepended and commercial-at '@' and number of bytes stack space appended).

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.

I have little desire to write a whole new build toolset, though that will have to be done eventually, I think. The only other tools required would be a Windows-native version of Readline--not because ghci can't be built using the Mingw version but because the GHC producing the Windows version will be using lib.exe to link. Since lib.exe can't handle Mingw static (.a) libraries I either need to find or port those libraries.

Cheers,
Pete

_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to