Keeping binary compatibility
thiago at kde.org
Mon Oct 4 14:27:20 BST 2010
Em Segunda-feira 04 Outubro 2010, às 14:13:46, George Kiagiadakis escreveu:
> On Sun, Oct 3, 2010 at 8:55 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 03.10.10 13:23:17, George Kiagiadakis wrote:
> >> However, this might be acceptable if BIC changes are documented for
> >> each release, so that we know when different module versions can be
> >> mixed and when they cannot. This will at least reduce the pain when
> >> users need to mix different versions that *can* be used together. Of
> >> course, the best way to achieve this would be to bump (or not bump, if
> >> there is no BC break) sonames, which is immediately visible to the
> >> packagers. So, I think we are back to the original proposal :)
> > I think in most cases you'll simply get a new soname with each release
> > of the KDE modules because most devs don't (want to/can) care about
> > wether a particular change they're doing is bc or not. So they end up
> > increasing soname shortly after trunk is unfrozen and thats not going to
> > benefit you either (except that it would document that any two minor
> > releases are incompatible).
> Well, there are tools to check for binary compatibility. In debian we
> use a symbols checker (which is not perfect though because it only
> checks the exported symbols, not the members of classes and the
> virtual tables) and now Lubos has presented a new abi checker tool
> that seems more complete. Let's start using it.
You can also use the scripts and the code found in tests/auto/bic/ in the Qt
source tree. It doesn't check the exported symbol table, but it checks the
vtables and class sizes.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Qt Developer Days 2010 - Munich Oct 11-13 - San Francisco Nov 1-3
For more information and to register: http://qt.nokia.com/qtdevdays2010
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel