Em sexta-feira, 17 de março de 2017, às 13:02:36 PDT, Marc Mutz escreveu: > On Friday 17 March 2017 17:16:39 Thiago Macieira wrote: > > Em sexta-feira, 17 de março de 2017, às 03:31:23 PDT, Marc Mutz escreveu: > > > provided the same external libraries, and the same toolchain are used to > > > build the two Qt releases. > > > > The problem is this line here. People expect to upgrade other libraries. > > We should say that we guarantee our ABI provided that libc and the C++ > > library guarantee it too. We won't expose any other library's types in our > > ABI. > > This is false already today. Or only true for a definition of "libc" that > approximates "all libraries Qt depends on".
Actually, I meant what I said but I realise that it's not accurate. I was going to say "our dependencies", but I wanted to constrain what we actually do expose. We depend on libdoubleconversion and libpcre2, but those aren't exposed in the API. But what I constrained to is inaccurate. > We use Mac types in the ABI. We > probably use Windows types in the ABI. We provide platform-native handles, > for one. Right. And specialised libraries like QX11Extras also expose Xlib types. > We expose OpenSSL in our ABI. Yes, we hide it behind a void* > Qt::HANDLE, but any user of QSslCertificate::handle() already depends on > OpenSSL. This is a SEP. Right, and QDBusConnection also provides a void* to get the DBusConnection, but I've warned that it may change. Note that exposing a void* actually means we *don't* depend on their ABI and, if they break it, our ABI isn't affected. The code inside network/ssl or dbus can deal with the apparent breakage and hide the problem, if necessary. > Don't insist on making all libraries' ABI stability > _our_ problem. If it wasn't for this rule, QSslCertificate::handle() could > return the real thing, depending on the platform, saving the user the need > to write dangerous casts. I'd insist we keep it a void* (I invite you to take a look at qsslcertificate_winrt.cpp) the same way that the native event filter also does type-erasure. Converting back to the original type is SEP. > Let's say it like this: > > ... provided the libraries, toolchain and build settings (incl. compiler > switches) provide binary compatibility, too. Agreed, but I want a whitelist of libraries whose ABI we expose in our ABI. Libraries that are mere backends of what we implement should not be exposed. > iow: Qt will not introduce spurious binary incompatibilites not already > present in libraries, toolchains and settings Qt depends on. Agreed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
