http://bugzilla.opensuse.org/show_bug.cgi?id=939434
http://bugzilla.opensuse.org/show_bug.cgi?id=939434#c1
Stanislav Brabec changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CONFIRMED
CC| |jengelh@inai.de
Flags| |needinfo?(jengelh@inai.de)
--- Comment #1 from Stanislav Brabec ---
There was a large discussion about it seveal years ago:
- STL + Unicode is the configuration of wxWidgets recommended by the upstream.
- ANSI (i. e. not Unicode) version should be considered as strongly deprecated
- STL should be preferred over wxcontainer.
- 2.4 API is also deprecated.
And yes, all three STL, Unicode and 2,4 compatibility changes the API and ABI,
which makes packaging especially complicated.
In the version 2.8, the package spec file generated several variants: defualt
(the STL container, Unicode enabled, 2.4 compatibility disabled), ansi (the old
container, Unicode disabled, 2.4 compatibility enabled), wxcontainer (the old
container, Unicode enabled, 2.4 compatibility disabled), wxcontainer24c (the
old container, Unicode enabled, 2.4 compatibility enabled; Fedora ABI
compatible).
When it was update to version 3, Jan Engelhardt decided to drop other variants
and keep only the default one, considering having a four incompatible packages
as an overkill.
Note that wxWidgets never supported this multi-variant setup. This always
needed some additional tricks: adding RPATH tags to target binaries required
patching of wx-config, and some programs ignored this additional option.
It was expected that everybody who ported application to wxWidgets 3 also made
it compatible with STL and Unicode.
We cannot easily disable STL:
- It will break ABI
- Some programs already require STL
If your package depends on wxWidgets 3 compiled without STL, it would be needed
to do something line wxWidgets 2.8 did. Jan, do you think that it makes sense?
--
You are receiving this mail because:
You are on the CC list for the bug.