Re: MSYS mode (continue)

[LRN <lrn1986 at gmail dot com>]

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

On 29.07.2013 19:47, Corinna Vinschen wrote:
> On Jul 29 19:36, LRN wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 29.07.2013 15:18, Corinna Vinschen wrote:
>>> On Jul 29 15:00, LRN wrote:
>>>> On 29.07.2013 13:29, Corinna Vinschen wrote:
>>>>> On Jul 27 20:17, NightStrike wrote:
>>>>>> Perhaps it would be useful to actually identify which packages have
>>>>>> extenuating needs.  Maybe it's just one or two.  Maybe it's all but
>>>>>> one or two.  I don't think that currently, the problem space is
>>>>>> properly enumerated, but is instead living in the abstract.
>>>>>
>>>>> Very good point.  This would perhaps show us much better where we're
>>>>> heading here.  From the current input I only see the following required
>>>>> changes in relation to a stock Cygwin distro:
>>>>>
>>>>> - gcc targeting Mingw rather than Cygwin.
>>>> You already have that, it's called "mingw cross-compiler for cygwin".
>>>> And that is not what msys users use.
>>>> I think you've meant something different here, i'm not sure what.
>>>
>>> to produce mingw executables (aka "native Windows
>>> exectables running without a compat layer") to avoid cross compiling
>>> when creating native Windows executables.  If the native gcc in an MSYS
>>> install targets MSYS, and if you had to use a cross compiler to create
>>> native Windows executables (as in Cygwin), there would ne no reason for
>>> MSYS at all since it would be equivalent to Cygwin.
>>
>> Yes. In this case i don't see how Cygwin fits in here. Unless you
>> suddenly decided to become a MinGW toolchain vendor.
>> /usr/bin/gcc is a cygwin gcc that targets cygwin
>> /mingw/bin/gcc is MinGW gcc that targets W32.
>>
>> Anything that resides in /mingw is completely outside of cygwin domain,
>> which is why i was surprised to hear that you wanted to provide mingw gcc.
>>
>> I would expect people to get cygwin/msys in one place, and get MinGW in
>> another. Even mingw-get, while being a source of both msys and mingw
>> packages, clearly distinguishes betweent he two.
> 
> 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.

The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin.

The problem is that the convention that everyone has been following for
years now is that all mingw stuff lives in /mingw, and all msys (cygwin)
stuff lives in /usr. These two are never mixed.

If you start providing alternative gccs, that might confuse people. A
lot. Since for people who installed cygwin-gcc, gcc.exe will produce
cygwin binaries, while the ones with mingw-gcc will have a gcc.exe that
produces mingw binaries. Also, how will you have both cygwin-gcc and
mingw-gcc installed at the same time (some people do need that)?

Relying on prefixes (i686-pc-cygwin-gcc and i686-w64-mingw32-gcc) might
work, but not all packages are prefix-aware.
This also brings us back to the distinction between native and
non-native toolchains. To have both gccs in /usr, you'll have to make
them look for stuff in /usr/$target/{include,lib}. Can't have both mingw
and cygwin libs/headers in /usr/{lib,include}, obviously.
While that might work, i'd guess that it will also break in a some
cases, where people (and scripts) expect that $prefix/{lib,include} are
the right dirs to use.

If it looks in $prefix/$target/{lib,include} and has a name $target-gcc,
then from user's point of view it's a cross-compiler (even if has
build==host==target), and we've already decided that you already have a
cross-compiler and don't need another one.

/mingw also provided a way to swap mingw subsystem (just edit /etc/fstab
to make /mingw point to a different dir, then restart the shell). With
everything living in /usr that might be unnecessary, but now that i
think of this...how are you going to separate compiled binaries from
each other? Say, your /usr/bin/i686-w64-mingw-gcc builds libxml2-2.dll.
That lands in /usr/bin. And when you compile libxml with
/usr/bin/x86_64-w64-mingw-gcc, it builds libxml2-2.dll, and it lands
into the same directory. Where else could it go? /usr/i686-w64-mingw/bin
or /usr/x86_64-w64-mingw/bin? I've never seen mingw doing that kind of
stuff. And how are you going to maintain PATH for them?
If you propose to have only the toolchain in /usr, but build&install
everything with --prefix=/mingw...that, again, might work in some cases,
but not the others. Also, which packages are "the toolchain"? You will
also need to configure gcc that lives in /usr to look for headers/libs
in /mingw/{include,lib}.

So i'd suggest to stick with /usr and /mingw convention and let mingw
take care of itself. It's simpler that way.

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

iQEcBAEBAgAGBQJR9wyWAAoJEOs4Jb6SI2CwkQ4H/iumE/JGhaPRrYrYygRTByht
9r+sTWocYtEeec1pM+Uza4lW9z03gMlcV5JZNM+UJ7d/mrJLFPFNBXR6B1PCZb7q
sPq/XGB0JdY/mhDQ7Zm6nzW1lTFucEoNQh/KHc6yiRJwkaKVgt1erkQVznOtTvCq
ZKk9HLqUx4zf6OVk7iJLNS9Y0pBesXmXljo3N4/iYKsRvGa3a1qWd7AmEmEKeYBU
AfBQezkmP1/L/alNB5oNCAA7yj2W+ilfz5sUHVyq6EeXjQlr+xKvuJ8M/gTp6lYa
6946x414ANr3pCXa/Du3coN2372zydssxnRcOqW5SgL8L6l1orsvnfYpuJ2QuOo=
=E7Iz
-----END PGP SIGNATURE-----