MSYS mode (continue)

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29.07.2013 20:37, Charles Wilson wrote:
> 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.
> 
> 
> 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).

That might work. It also means that you'll need a new cygwin
cross-compiler (a mingw->cygwin cross-compiler, although in reality it
might be cygwin->cygwin native compiler that looks like a
cross-compiler). Unless existing one can be stuffed into
/usr/i686-pc-cygwin without any ill effects.

> 
> 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.
Yes, LRN is assuming that /usr/bin/gcc is a cygwin-gcc, and
/mingw/bin/gcc is a mingw gcc.
$MSYSTEM/$PATH games worked well enough so far.

> 
> 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.
Yes, that is a good point.

> 
> 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.
Yes, but with cygwin that is going to go away, as i686-pc-cygwin IS a
valid triplet. More reasons to not to let mingw apps see these autotools
and m4 files.

> 
> The /mingw version of the autotools was not hacked in this way.
Though it might be hacked in other, unspecified ways (for example, i
mess with stuff a lot to integrate W32 CPython; this is not needed for
msys-python).


You've laid out advantages and "advantages" of the former system.
What are the advantages of the latter system?

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJR9xRSAAoJEOs4Jb6SI2CwZgUH/0O53vyz6+QfwWFYBWCtsXl9
yIwVEoEQY7GmwFFPRXLiZkh8EQx2/xKdZrpwFGVHPb/hFyYuBPjDkzDlWV6KrFBh
o3YKPlZjPw1gyD+p03ekFkxpgPgZpucaR0k54UyqnnXAtZwA8NhToMokxPJVKez3
e4gpM+dmmpWWsZLQl7I1ZwOTnG88B7aySt8nphGpfUCtfWGzaKU+6JN48HzQapHU
7Wj30Ashmt1eI9LJK5kz+RnBEzdrYlsJITDa+BdHBSFhgqZsMc/DothBmcxi4hl4
ZPFWi6ErAggdkIHrYku1/YUjDjZ19KXHkerY+0y9QwQAJUVZ0iSaau82C3EIZcY=
=p74t
-----END PGP SIGNATURE-----