Re: [PATCH] Support MSYS2

[Peter Rosin]

On 2015-08-09 21:26, address@hidden wrote:
> The output of uname -o is indeed the same in MSYS2 and MinGW/MSYS
> 
> Msys
> 
> However, that is irrelevant because, config.guess does not use uname -o, it 
> does uname -s
> 
> UNAME_SYSTEM=`(uname -s) 2>/dev/null`  || UNAME_SYSTEM=unknown
> 
> The output of uname -s is different between MSYS2 and the old MinGW/MSYS, and 
> that's the reason why config.guess (at least the latest versions of it) 
> returns something different between MSYS2 and the old MinGW/MSYS. So the 
> patch is ultimately necessary

But the problem is that msys 1.0 uses the envvar MSYSTEM to control
the output of uname -s, and traditionally it is set to "msys" when
building tools for msys 1.0, and to "mingw" in the normal end-user
use case where you want MSVCRT instead of the msys C library.

I have the feeling that this patch tramples on this aspect of the
original msys (1.0). Which is not nice...

Since the patch changes branches that were formerly mingw but not
cygwin, I guess that the patch is aiming for changing the case where
msys is used in its normal use case targeting MSVCRT. If I have
assumed wrong here, then the patch is clearly suspect.

But why would you want to change the host-triplet from mingw* to
msys* in the case that my assuption is correct? That would break
a lot of packages that has already been ported to mingw, no?
When you cross-compile from linux using a mingw toolchain, you still
use a mingw* host-triplet, why you you want to wander away from
that when you use the mingw toolchain from msys2? So, the patch is
suspect even if my above assumption is correct.

Cheers,
Peter