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=494283
Kalev Lember <kalev(a)smartlink.ee> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fedora-mingw(a)lists.fedorapr
| |oject.org
Blocks| |177841(FE-NEEDSPONSOR)
Depends on| |454410(mingw32-gcc)
Alias| |mingw32-libp11
--
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.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Review Request: mingw32-libsigc++20 - MinGW Windows port of the typesafe signal framework for C++
Alias: mingw32-libsigc++20
https://bugzilla.redhat.com/show_bug.cgi?id=492110
Summary: Review Request: mingw32-libsigc++20 - MinGW Windows
port of the typesafe signal framework for C++
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: Package Review
AssignedTo: nobody(a)fedoraproject.org
ReportedBy: t.sailer(a)alumni.ethz.ch
QAContact: extras-qa(a)fedoraproject.org
CC: notting(a)redhat.com, fedora-package-review(a)redhat.com,
fedora-mingw(a)lists.fedoraproject.org
Classification: Fedora
Spec URL: http://sailer.fedorapeople.org/mingw32-libsigc++20.spec
SRPM URL:
http://sailer.fedorapeople.org/mingw32-libsigc++20-2.2.2-5.fc11.src.rpm
Description:
MinGW Windows port of the typesafe signal framework for C++
This is just Richard M. W. Jones unmodified Spec file.
Approved MinGW packaging guidelines are here:
http://fedoraproject.org/wiki/Packaging/MinGW
--
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.
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