This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: MSYS mode (continue)
- From: LRN <lrn1986 at gmail dot com>
- To: cygwin-developers at cygwin dot com
- Date: Tue, 30 Jul 2013 05:18:10 +0400
- Subject: Re: MSYS mode (continue)
- References: <20130725150209 dot GA15619 at calimero dot vinschen dot de> <51F16C82 dot 7030509 at cwilson dot fastmail dot fm> <20130725205320 dot GA2725 at ednor dot casa dot cgf dot cx> <20130726081510 dot GN5086 at calimero dot vinschen dot de> <51F3394A dot 6050309 at cwilson dot fastmail dot fm> <CAF1jjLv_znaB_EH4LDo_xTq3d+-QuZR3R5jWQYpKiZJdDPKWFA at mail dot gmail dot com> <20130729092958 dot GB3731 at calimero dot vinschen dot de> <51F64B38 dot 8000500 at gmail dot com> <20130729111856 dot GD30069 at calimero dot vinschen dot de> <51F68BED dot 5010506 at gmail dot com> <20130729154725 dot GD4166 at calimero dot vinschen dot de> <51F69A57 dot 5060908 at cwilson dot fastmail dot fm>
-----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-----