Hi Olaf! On Thu, 23 Apr 2020 at 12:02, Olaf Mandel <o.man...@menlosystems.com> wrote: > > Dear Lisandro, > > Am 23.04.2020 um 14:19 schrieb Lisandro Damián Nicanor Pérez Meyer: > > On Thu, 23 Apr 2020 at 07:27, Olaf Mandel <o.man...@menlosystems.com> wrote: > >> QT += quickcontrols2-private quicktemplates2-private > >> > >> Currently, such a compile fails as the *.pri files (not to mention the > >> header files) are missing. > >> > >> Note that while compiling against Qt private modules may not be good > >> form, it is allowed and I would expect this to be possible with > >> Debian-provided Qt modules (it is with the qtbase ones). > > > > We do indeed remove all private headers except for the ones required > > by another submodules (that's why qtbase ships them). > > [...]> That's a very bad idea, private headers are not API/ABI stable. > > > Couldn't this uncharitably be reinterpreted as "we remove these headers > for others use as undesired because they are not API/ABI stable... > except for cases where we ourselves need them"?
Exactly that, yes. > What is the difference between Debian-maintained packages and > user-compiled software that justifies making compiling the latter more > difficult than the former? In Debian-packages, the Build-Depends/Depends > fields can be set to the exact version of the dependent library to > ensure API/ABI compatibility. Why couldn't the user do something > similar? Or if/when they don't recompile after an upgrade, then this is > the users lookout (IMO). Because in our use case (qt submodules) we know beforehand that the API/ABi will work, because it's a matter of splitting Qt into submodules (we could build Qt from one huge tarball, but that would be insane). We are currently forced to do transitions on **every** Qt upload, and the amount of work third party apps using private headers gives us is defintely more than enough. So yes, the less private headers, the better. > > > *Maybe* we can add the private headers for everything in the last Qt 5 > > upload, as it will switch to Qt 6 after all. But that's to be decided. > > > I am not sure that this would match my expectations: Once Qt6 comes out, > I would probably rewrite my code to compile under Qt6 and if I still > needed the private parts, I would have this same problem again until Qt7 > comes out... Exactly. Don't use private headers. If you need them work with Qt upstreams to make them public API. > Given both of these points, I at least would prefer to have the private > headers available, even to non-package developers. The one thing I could > understand is that the private headers are in a new package > qtquickcontrols2-5-private-dev instead of in the "normal" > qtquickcontrols2-5-dev. That might serve as an extra level of warning to > the user. People would still use them in their packages, so no. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
