Re: [Development] Use of std::function in Qt API
Em sexta-feira, 17 de março de 2017, às 09:25:04 PDT, Matthew Woehlke escreveu: > > We are not talking about security problems. What is wrong with running a > > half-year, or worst case maybe even a two year old version of some library > > as base for the bulk of the applications? > > No bug fixes? No new features? Inability to update applications that > need the new features? Delay in developers being able to use new > features because their users don't have the latest version? I completely agree on the bug fix issue: bug fixes are required. Before Qt 5.8, our habit was of releasing one or two patch releases, then stopping update and telling people to upgrade to the next minor. It's irresponsible to not provide an update path: we must provide patches to releases we're telling people to use. If we're saying "it's ok for you to stay in that year-old minor series", then we have to provide patches for it. Conversely, if we close that minor series' branch and tell users to upgrade, then they must be able to upgrade without rebuilding the world. 5.6 comes in to help, but we've already been irresponsible in not releasing 5.8.1 again. Our track record is not good. As for the features, I take a middle-road: if a distribution has as policy not updating across minor versions for anything, then nothing requires new features in the first place. Just bugfixes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of std::function in Qt API
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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of std::function in Qt API
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". We use Mac types in the ABI. We probably use Windows types in the ABI. We provide platform-native handles, for one. 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. 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. Let's say it like this: ... provided the libraries, toolchain and build settings (incl. compiler switches) provide binary compatibility, too. iow: Qt will not introduce spurious binary incompatibilites not already present in libraries, toolchains and settings Qt depends on. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of std::function in Qt API
On 2017-03-17 12:17, Thiago Macieira wrote: > Em sexta-feira, 17 de março de 2017, às 02:43:05 PDT, Tobias Hunger escreveu: >> A distribution will not update the standard c++ library within a distro >> release. >> Neither will a distribution upgrade Qt minor versions within a >> distro release. > > Both assertions are incorrect. What Thiago said. Also, FWIW, I prefer when distros *are* willing to make minor-version updates to libraries even within the same release of the distro. (Provided of course such updates don't have breaking changes.) Also, if Qt gets into a habit of skipping bug fix releases, distros may get more pressure to do just that in order to get important bug fixes. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of std::function in Qt API
On 2017-03-16 19:26, André Pönitz wrote: > On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote: >> On 2017-03-14 13:33, André Pönitz wrote: >>> In general, I am not overly sold on ABI compatibility promises. I personally >>> could live without and find SC of more practical value. The most important >>> "feature" of ABI compatibility guarantee for me is that it limits people >>> from >>> doing overly excessive source-incompatible changes. >> >> Distros are likely to care; a Qt BC break requires a mass rebuild of >> everything that uses Qt (which translates into lots of users needing to >> update lots of packages when Qt changes). > > I am three steps away from understanding what you are saying: > > I don't get why a library (Qt or anything else) BC break would cause a distro > to > update packages outside their usual upgrade cycle (when most, or rather all, > of > the packages will be recompiled anyway) 1. You assume that distros never update packages outside of distro updates? 2. What about rolling distros? > nor, in case the distro did it nevertheless, do I understand why a > user would need to upgrade packages in that case, nor, in case the > distro *and* the user consciously decided to upgrade, why that would > be a problem. Addressed in Thiago's reply. >> Distros may refuse to update Qt within a distro release as a result, which >> means >> users are stuck with older Qt for longer. > > Yes, and, so what? > > We are not talking about security problems. What is wrong with running a > half-year, or worst case maybe even a two year old version of some library > as base for the bulk of the applications? No bug fixes? No new features? Inability to update applications that need the new features? Delay in developers being able to use new features because their users don't have the latest version? >> All that more or less already applies to the standard library however >> (probably >> most distros don't accept a standard library BC break without a mass rebuild >> anyway), so Qt insulating against BC breaks in the standard library is maybe >> less necessary. > > That was the starting point here. Not Qt breaking BC by itself, but allowing > C++ > BC breakages to affect otherwise "pure Qt" applications. Right. My point is I think it's okay for Qt to not bend over backwards to insulate its users from BC breakages of Qt's dependencies (in particular, the C++ standard library), since the efficacy of that "shielding" is debatable. I don't think it's okay to extend that to license for Qt to break *its own, internal BC*, which is what your previous post seemed to be implying. On 2017-03-17 05:32, Viktor Engelmann wrote: > We are talking about BC breakages that happen because of libstdc++ > BC breakages. Are we? That wasn't at all obvious from André's previous message. > I think it might be wisest to allow BC breakage under the premise that > the major version number must change whenever BC is broken. We already do that. (We also allow SC breaks between major versions.) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of std::function in Qt API
Em sexta-feira, 17 de março de 2017, às 02:43:05 PDT, Tobias Hunger escreveu: > A distribution will not update the standard c++ library within a distro > release. > Neither will a distribution upgrade Qt minor versions within a > distro release. Both assertions are incorrect. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of std::function in Qt API
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. But please note how the libstdc++ break was both source-compatible and binary- compatible for the direct users of that library, but caused BC breaks downstream. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of std::function in Qt API
On Friday 17 March 2017 10:19:10 Ulf Hermann wrote: > Let's just allow standard library types in Qt, and document that the BC > guarantee only extends across compatible standard libraries. The Qt BC guarantee should only cover Qt. It should explicitly exclude compiler switches, libc, stdlib, boost, libclang, ... libraries. IOW: Qt guarantees that: 1. two different patch releases of the same Qt minor release are binary compatible with each other, and 2. that a younger minor release is binary compatible with any older minor release of the same major Qt release, provided the same external libraries, and the same toolchain are used to build the two Qt releases. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of std::function in Qt API
On Thu, 2017-03-16 at 13:23 -0400, Matthew Woehlke wrote: > On 2017-03-14 13:33, André Pönitz wrote: > > In general, I am not overly sold on ABI compatibility promises. I personally > > could live without and find SC of more practical value. The most important > > "feature" of ABI compatibility guarantee for me is that it limits people > > from > > doing overly excessive source-incompatible changes. > > Distros are likely to care; a Qt BC break requires a mass rebuild of > everything that uses Qt (which translates into lots of users needing to > update lots of packages when Qt changes). Distros may refuse to update > Qt within a distro release as a result, which means users are stuck with > older Qt for longer. I think this is not a real issue: A distribution will not update the standard c++ library within a distro release. Neither will a distribution upgrade Qt minor versions within a distro release. I do not expect patch version upgrades of Qt to introduce BC issues with or without it relying on std::functionality. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of std::function in Qt API
On 17.03.2017 06:39, Thiago Macieira wrote: > Em quinta-feira, 16 de março de 2017, às 16:26:20 PDT, André Pönitz escreveu: >> On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote: >>> On 2017-03-14 13:33, André Pönitz wrote: In general, I am not overly sold on ABI compatibility promises. I personally could live without and find SC of more practical value. The most important "feature" of ABI compatibility guarantee for me is that it limits people from doing overly excessive source-incompatible changes. >>> Distros are likely to care; a Qt BC break requires a mass rebuild of >>> everything that uses Qt (which translates into lots of users needing to >>> update lots of packages when Qt changes). ... >> nor, in case the distro *and* the user >> consciously decided to upgrade, why that would be a problem. > Because if there's a BC break, then all the packages linking to that library > would need to be upgraded, all at the same time. If every library did this, > at > uncontrolled points in their releases, every single bugfix would require > building everything that changed downstream from it and thus downloading it > all and installing. >> That was the starting point here. Not Qt breaking BC by itself, but allowing >> C++ BC breakages to affect otherwise "pure Qt" applications. > Distros did shield from rebuilding after the libstdc++ breakages. But I am > with others now saying that we shouldn't have to go out or our way to do > that. > If libstdc++ does it, it's for a good reason. I see some valid concerns here, but I think in practice, André is right. We are talking about BC breakages that happen because of libstdc++ BC breakages. If distros switch from one libstdc++ to a binary incompatible libstdc++ *between releases*, then it's their own fault they have to rebuild and redeliver everything. And if they don't, then qt libs don't break BC either, so there is no problem in that case. I think it might be wisest to allow BC breakage under the premise that the major version number must change whenever BC is broken. That would tell people loud and clear that they have to rebuild (also the library names are likely to change then, so old versions of a program can't accidentally load the binary incompatible library) -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of std::function in Qt API
> All that more or less already applies to the standard library however > (probably most distros don't accept a standard library BC break without > a mass rebuild anyway), so Qt insulating against BC breaks in the > standard library is maybe less necessary. This is the important observation. Hardly anyone (actually, is there anyone besides Qt?) guarantees resilience against standard library BC breakages. So, if the standard library breaks BC and the distribution accepts the new version, then it doesn't really matter what Qt does with it as all packages that use the standard library, including ones that also use Qt, will have to be rebuilt. C++ packages that don't use the standard library are rather rare. Let's just allow standard library types in Qt, and document that the BC guarantee only extends across compatible standard libraries. Ulf ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
