[Bug 673784] Rename Request: mingw32-filesystem -> cross-filesystem - Cross compiler base filesystem and environment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=673784

--- Comment #6 from Ralf Corsepius <rc040203@xxxxxxxxxx> 2011-01-31 05:52:25 EST ---
(In reply to comment #5)
> As mentioned on the link in the initial message the plan is to rename all
> current mingw32-* package to cross-*.
With all due respect, to me this plan is beyond reason, because mingw, rsp.
their 2 sub targets mingw32 and mingw64 are only a very small subset of
cross-targets.


> I'm okay with using a different prefix like the crossdesktop-* which Richard
> suggested if you prefer that

IMO, mingw-filesystem would be an appropriate name, because that's what it
currently is - The rest of it is wishful thinking.

> The target name x86_64-w64-mingw32 might look a bit odd for outsiders, but it's
> the default target name used by the mingw-w64 developers.
Well, ... this doesn't mean their decisions are wise ;)

x86_64-w64-mingw32 (cpu=x86_64, os=mingw32) is multiply problematic:
- the "32" in mingw32 originally stood for "MinGW on 32bit Windows",
=> a 64bit MinGW for "MinGW on 64bit Windows" should be named "mingw64"
- Configure scripts currently presume "os=mingw32" to imply 32bit MinGW.
...

I.e. to me reasonable choices would be
x86_64-pc-mingw + i686-pc-mingw
or 
x86_64-pc-mingw64 + i686-pc-mingw32

> I just dropped the
> question about the history behind that name in the #mingw-w64 IRC channel and I
> got multiple answers back. The main reason is compatibility. Think about the
> autotools where a large amount of checks look for the term 'mingw32' in the
> target to find out whether the target is a MS Windows one. When the 'w64' part
> in the target name is used

The 2nd field of a target-triple is the "vendor"/"manufacturer" field, which
originally was meant to be the hard-ware manufacturer of a specific board,
which later became abused by Linux-vendors to put their brand into (*-redhat-*,
*-suse-*).

I.e. if mingw wants to follow the "HW vendor" path, their 2nd field should be
"pc" (The generic value), rsp, if they want to follow the SW vendor path, it
should be "microsoft".

In any case, the vendor field is without much practical importance and unused
in 99% of all configure scripts (ignored).

What matters are the "cpu"-field and the "OS" field - They need to provide
sufficient information for configure scripts to destinguish architectures and
OSes.

That said, I consider x86_64-w64-mingw32 to be a mistake.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review


[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]