MSYS mode (continue)

[Charles Wilson]

On 7/29/2013 11:47 AM, Corinna Vinschen wrote:
> That's what I understood differently.  From the discussion on mingw-w64
> it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
> gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.

I agree with Corinna here.  I think LRN is assuming that the 
installation structure will remain the same as MinGW/MSYS going forward, 
and I do not believe that is correct -- at least, that's not what 
Corinna is proposing IIUC.

Here's how MinGW/MSYS works right now:

*normally* the batch file you use to enter the "MinGW" environment, 
launches bash with
	1) MSYSTEM=MINGW32
	2) /mingw/bin at the "front" of $PATH (wherever your mount
	   table happens to say that is)

Your phyiscal directory structure *normally* looks something like this:

C:\MinGW      <<<<< mounted as /mingw
      bin      MinGW (that is, "native" win32) gcc.exe & friends
      include  "native" win32 headers
      lib      and libraries
      msys
         1.0   <<<<< mounted as /
             bin    gcc.exe -- only this time, it's an
                    msys-target compiler. But note that it is
                    actually configured as a "native" compiler
             include   msys headers and
             lib       libraries

Because of #1 and #2 above, uname reports MINGW32, and the first gcc 
found in your path is the "native" win32 MinGW one.

However, an *msys* developer would launch a script that invokes bash with
	1) MSYSTEM=MSYS
	2) /bin at the "front" of $PATH

In this case, uname reports MSYS, and the first gcc found in your path 
is the msys one.

=====-----=====

In the new scenario, we might have a separable installation -- maybe
    c:\msys\2.0\
but there isn't any gcc.exe installed there.  And then you might install 
MinGW gcc somewhere like
    c:\MinGW-4.8.1\
and just arrange that
    c:\msys\2.0\etc\fstab
has
    c:\MinGW-4.8.1\   /mingw

and again, you make sure that /mingw/bin is in your $PATH.

However, in the new scenario, you MIGHT have, in 
c:\msys\2.0\i686-pc-cygwin\, a cross compiler targetting "cygwin/msys" 
and running on...MinGW (even though "MinGW" environment is, for all 
intents and purposes, a slightly modified cygwin -- but uname reports 
MINGW32 just like it does for "native" MinGW/win32 operation).  To build 
msys apps in this environment, you have to use --host=i686-pc-cygwin 
(and remember, because uname is reporting "MINGW32", any build system 
will operate under the assumption that you are, in fact, cross compiling).

There are some advantages to the former system, not least of which is 
that when MSYSTEM=MSYS, you're compiling natively so you can easily run 
any test suites without having to play games with the build system.

I think LRN is assuming that the gcc installed in /bin would be the 
cygwin gcc (configured as a native compiler), and we'd continue to play 
$MSYSTEM/$PATH games.

One additional "advantage" to the former system is the autotools. Right 
now we can have a "clean" separation between aclocal/.m4 files that have 
data corresponding to MinGW-compiled native libs and tools, and 
aclocal/.m4 files that have data corresponding to the msys ones -- 
because we have two entirely distinct "sets" of autotools.

/mingw/* has the whole panoply of autoconf2.1/2.5/wrapper, 
automake1.4--1.12/wrapper, libtool, gettext, and libintl.  All are 
configured with --prefix=/mingw, so they look in /mingw/share/aclocal*/ 
for .m4 stuff.

OTOH, in /{bin,lib,share} we have one specific version of autoconf (2.59 
IIRC), one specific version of automake (1.11?), libtool specially 
hacked to support msys (because "regular" libtool does not), gettext, 
and libintl.  Because msys has never been, and was not intended to be, a 
public "triple" value, these versions' config.guess/config.sub were 
modified to recognize the MSYS uname, and report i686-pc-msys as a 
triple, and to actually handle that triple correctly.

The /mingw version of the autotools was not hacked in this way.

This way, when porting some package in /mingw land and running 
re-autoconf, users don't get "fooled" by picking up stuff in 
/share/aclocal/* -- they only "see" the .m4 files that correspond to 
OTHER fully-ported-to-mingw libs and tools.

--
Chuck