mingw-w64 proposed changes to the triplet

[Richard W.M. Jones]

If you have any comments on this, best to take them up with Kai on
#mingw-w64 on OFTC.

Rich.

<ktietz> morning

<ktietz> we are currently in the decision finding about an extended
target triplet for mingw-w64.

<ktietz> there are at the moment three different approaches. All have
their advantages and disadvantages.

<ktietz> first is introducing an triplet with new OS part, e.g
something like <cpu>-pc-mingw64

<ktietz> second, is to add configure checks about probing the used
target runtime headers to enable our additional features

<ktietz> and the third is, to use the vendor key in triplet,
e.g. <cpu>-ms-mingw32*

<ktietz> so I would like to hear your opinion about this.

<ktietz> this step is getting necessary, because we want to support
multilib, and -municode feature. But mingw.org can't follow us in this
set at the moment

<ktietz> all those features should be available for 32-bit and 64-bit
targeting. So we have to split out here those incompatible
features. On the other hand we want still support a compatiblity mode
with the old triplet, which simply doesn't have those new features in
gcc

<rjones> not sure what to say except (1) we use the triplet as part of
the directory structure /usr/x86_64-pc-mingw32/ for example, (2)
changing it is extremely time-consuming, so don't change it more than
you need to, and (3) our policy is to follow upstream, ie. you

<ktietz> this was the reason to use here the vendor part of the key

<ktietz> so you can build in the compatibility mode to mingw.org and
if you use it with ms or w64 (the vendor name isn't fix until now) to
build with new features

<ktietz> IMHO this is the solution with most less negative
side-effects

<ktietz> most less=less

<rjones> ktietz, we haven't rolled out any mingw-w64 packages
officially yet, that's in the plan for our next cycle, starting
may/june.  All we have at the moment are unofficial/experimental
packages, so backwards compatibility isn't much of a concern.

<ktietz> ok, the idea here was, that we do not move to far away from
mingw.org

<ktietz> but we can fix for example the mingw directory issue, doing
multilib without the need of interfering with mingw.org, and are able
to add features like unicode support



-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora