Win-GHC with GnuWin32 toolset--Mingw32 replacement

[Peter Tanski]

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