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.mandel@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"? 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). > *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... 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. Best regards, Olaf Mandel
Attachment:
signature.asc
Description: OpenPGP digital signature