
The question is, is there any reason that the program might want to know that it is running on top of "mingw32" rather than plain "Win32". mingw32 does provide more - it has more of a posix-like C library than the basic C runtime that Win32 provides (msvcrt), so there is a difference. mingw32 is the only native Windows build we have right now, but it's not inconceivable that we might have an even-more-native build in the future, by bypassing mingw32 altogether. However, most of the time you just want to know whether you're on Windows vs. everything else, so mingw32 is too specific. I guess I'm saying mingw32 doesn't really do much harm, and it's "correct" in some sense, but we should also have provided #ifdef win32_HOST_OS for those cases when you don't care. Cheers, Simon I'm not sure it wrong, per se, just more specific than you want most of the time. On 11 November 2005 01:37, Neil Mitchell wrote:
I noticed GHC also gets it wrong in this case, with the same result. It's a bit of a shame, but maybe its too late to change...
On 11/10/05, Ross Paterson
wrote: On Thu, Nov 10, 2005 at 01:14:34PM +0000, Neil Mitchell wrote:
The function System.Info.os on WinHugs returns "mingw32", which is not really true. I guess its because the libraries are compiled using mingw32, since they can't be compiled natively from windows? Is there some way to alter the library build scripts?
As MinGW produces native binaries, "mingw32" isn't an appropriate value for os in any case -- it should be "mswin32" or the like, whether the Win32 binary was compiled with MSVC or MinGW. However "mingw32" is the name used by autoconf, and it's pervasive in the libraries. Maybe it should be special-cased in System.Info.
Then again, Cabal uses the values of System.Info.{arch,os} to construct the CPP symbols to be defined when preprocessing packages for Hugs, and package authors have #ifdef mingw32_HOST_OS all over the place.
_______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs
_______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs

mingw32 is the only native Windows build we have right now, but it's not inconceivable that we might have an even-more-native build in the future, by bypassing mingw32 altogether. The Windows build might be made using mingw32, but it runs natively without relying on mingw32, as far as I can tell. It certainly runs on my windows OS without having mingw32 installed (other than the bits ghc installes additionally).
The WinHugs is now a genuinely 100% Windows build, using Visual Studio - only the libraries are preprocessed under Mingw32.
I guess I'm saying mingw32 doesn't really do much harm, and it's "correct" in some sense, but we should also have provided #ifdef win32_HOST_OS for those cases when you don't care. That would be nice.
Thanks Neil
participants (2)
-
Neil Mitchell
-
Simon Marlow