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