System.Info.os

[Simon Marlow]

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 <ross at soi.city.ac.uk> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/cvs-hugs
>> 
> _______________________________________________
> Cvs-hugs mailing list
> Cvs-hugs at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-hugs