NightStrike wrote:
> What's wrong with using the existing GNU triplet?
FWIW sorry for setting off this discussion (but thank you --- the
answers have been very helpful to me!). Luckily you provided a
good example that might help explain the purpose of Debian triplets
later in the thread:
> Dmitrijs Ledkovs wrote:
>> Are cygwin/msys/mingw people willing to support new triplet naming scheme?
[...]
> It's hard to change the past, and even harder
> to change long standing traditions. However, if it's at all possible,
> I fully support a change to triplets that actually make sense.
Having Debian arch names that are not rigidly aligned to GNU triplets
makes such changes easier to weather.
Keep in mind, as I have probably already shown, I am very new to this
(both dpkg and mingw). So please do not take anything I say as
gospel.
What's in a Debian architecture name?
-------------------------------------
Debian arch names are primarily used to name the Debian machine
architecture[1] for which a package is available. Each (binary)
package has an Architecture: field naming its machine architecture.
A given dpkg installation only manages packages for one
architecture[2], so where possible it is beneficial to make these
course-grained.
Example: i486-linux-gnu and i586-linux-gnu get the same
Debian architecture name ("i386").
Meanwhile they need to be fine-grained enough to ensure
interoperability --- e.g., if package foo depends on package libbar (= 5)
then any build of libbar 5 on the current architecture must be able to
provide the functionality foo needs.
Example: x86_64-linux-gnu and i686-linux-gnu get
distinct Debian architecture names ("i386" and "amd64").
[1]
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
[2] Nowadays there is some work on getting mixed-architecture (e.g.,
i386 + amd64) systems to work well with the packaging system but
that is hard. So I'll ignore it for the moment. :)
Relationship to GNU triplets
----------------------------
When you build and install dpkg for the first time, its configure
script will run ./config.guess and match the output against ostable
and cputable to figure out which Debian architecture this is. A given
Debian architecture can correspond to a variety of GNU triplets (as in
the example "i386" above).
When building a Debian package, the build script "debian/rules" has
access[3] to a DEB_HOST_GNU_TYPE variable representing the target
architecture's (preferred) GNU triplet. This value is generally
passed on to ./configure.
Example: on i386, DEB_HOST_GNU_TYPE gets set to
i486-linux-gnu. When Debian stops supporting 486s with
mainstream packages, that will presumably change to
i586-linux-gnu.
Over time it is expected that the matching and preferred GNU triplets
for a given Debian architecture might change. So mistakes in this
part are not a bit deal.
Debian triplets?
----------------
When building a Debian package, the build script "debian/rules" has
access to DEB_HOST_ARCH_OS, DEB_HOST_GNU_SYSTEM, DEB_HOST_ARCH_CPU,
and DEB_HOST_GNU_CPU variables, which generally get used to work
around architecture-specific bugs ("on such-and-such OS, disable
such-and-such optimization").
Example: the Debian triplet for the "i386" architecture
is gnu-linux-i386. So DEB_HOST_ARCH_OS is linux
and DEB_HOST_ARCH_CPU is i386. The "gnu-" part is
there to distinguish this from uclibc-linux-i386.
Notice that the ABI/libc part of the system name ("gnu" in the
example) is not exposed using the dpkg-architecture script, so build
scripts generally do not depend on it. That might change some day,
but it would require separating the ABI part from libc part to be
useful, so I wouldn't worry about it.
The case of mingw64
-------------------
mingw-w64-, mingw.org-, and cygwin-built libraries are not
interchangeable from an ABI point of view, so they have to be distinct
Debian architectures. (Thanks for correcting me multiple times on
this.) Let's just worry about mingw-w64 for the moment.
The operating system (kernel and user tools) is Windows (except maybe
for cygwin; I don't want to think hard about that). We can call it
mingw32, to be consistent with the GNU triplet (confusing!)
winnt, since I think that's the kernel's name
windows, for simplicity
windows sounds fine to me. This includes ReactOS as a special case,
as long as it lives up to its compatibility goals.
The C library is mingw-w64, which could be abbreviated as mingw64 or
w64. The meaning of mingw64 seems more obvious to me.
No need to tack on an ABI variant in addition to that. "mingw-w64,
on 32-bit x86" meets the requirements described in "What's in a
Debian architecture name" above, I think. So how about something
like this?
Dmitrijs, please locally try out whatever variant seems sanest to you
(and I will try to find time to test the cross-toolchain packages).
diff --git a/ostable b/ostable
index 17b7581..672dc13 100644
--- a/ostable
+++ b/ostable
@@ -31,3 +31,4 @@ bsd-openbsd openbsd openbsd[^-]*
sysv-solaris solaris solaris[^-]*
uclibceabi-uclinux uclinux-uclibceabi uclinux[^-]*-uclibceabi
uclibc-uclinux uclinux-uclibc uclinux[^-]*(-uclibc.*)?
+mingw64-windows w64-mingw32 w64-mingw[^-]*
diff --git a/triplettable b/triplettable
index 3e076e2..9cc6e5b 100644
--- a/triplettable
+++ b/triplettable
@@ -20,3 +20,4 @@ bsd-darwin-<cpu> darwin-<cpu>
sysv-solaris-<cpu> solaris-<cpu>
uclibceabi-uclinux-arm uclinux-armel
uclibc-uclinux-<cpu> uclinux-<cpu>
+mingw64-windows-<cpu> mingw64-<cpu>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
