Page 1 of 1

ABI compatibility plans

Posted: Thu Mar 03 2016 3:02 am
by ahmedcharles
Qt has traditionally had very strict ABI compatibility guarantees, which comes with some pros and cons. I'm curious what approach CopperSpice will take in this regard, since it impacts the types of changes that can be made over time. More specifically, the standard library does not have any inherent ABI compatibility and different implementations have different policies about it. More importantly, using standard library types at shared object boundaries is usually a bad idea from an ABI compatibility perspective.

I believe the spectrum would place Boost on one side (with almost no guarantees across releases) and Qt on the other (with very strict guarantees across releases) and LLVM (and subprojects) somewhere in the middle (some things have guarantees and other things don't). Given this diversity, I'm curious where CopperSpice wants to end up?

Re: ABI compatibility plans

Posted: Thu Mar 17 2016 5:18 pm
by ansel
Hi Ahmed,

You raise a good question and one which deserves a full discussion. We do not have a set policy yet, as the ABI (and the API as well) are in rapid flux.

We do believe that the Qt policy of strict ABI compatibility for an entire major version release is difficult to maintain for a rapidly evolving open source project. Since CopperSpice is not primarily a header-only library, the boost strategy seems inadequate from a user standpoint.

At the moment, our thinking is something more like the Linux kernel model, where version X.Y and X.Y+1 are maintained in parallel, with X.Y being an ABI-stable branch which only receives bug fixes and X.Y+1 being a development branch which makes no ABI guarantees.

This is not an official policy yet, and we invite your suggestions in shaping it.

Re: ABI compatibility plans

Posted: Fri Mar 18 2016 12:15 pm
by ahmedcharles
I'm mostly interested because lots of the changes that I have locally (or ones that will build on those) have ABI implications.

For example, I'd like to use std::unique_ptr<QWidget> to indicate transferring ownership of a QWidget to a function rather than just having it take a QWidget*.

For Windows, this likely doesn't matter, since applications will likely ship their own copy of copperspice with the application.

For Linux, this may not matter since both standard libraries tend to have good abi compatibility guarantees.

Just something to think about, I guess.