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 _______________________________________________ fedora-mingw mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
