On Thursday, 13 June 2019 05:02:01 PDT Lisandro Damián Nicanor Pérez Meyer wrote: > > Giving our build tools different names depending on the version can create > > other problems for our users, especially those that use some hand rolled > > build systems (and we probably have lots of those as well). > > And the above is clearly a thing a Qt-internals' developer should definitely > look to, so a very valid concern. But let's take the other's too.
I REALLY don't think there are a lot of hand-rolled buildsystems out there. And they must represent less than 0.1% of uses and complexity. We should consider giving them a solution. But by the same token, we should consider that Linux distributions must correspond to at least 10% of uses, which is 100x more. > We can list qdbus and qdbusviewer as examples (perhaps not the best ones, > but will do for now). So let's say app4 is compiled against Qt4 (we still > have them around, sadly not every useful app was yet ported) and app5 is > compiled against Qt5. Take Qt 6 instead of Qt 4 if you like. Both where > developed using their own version's qdbus in mind. > > As a packager my duty is to ensure that app4 has a strong dependency against > Qt4's qdbus and app5 has a strong dependency against Qt5's qdbus, so both > versions of qdbus will be installed. Those are really not good examples because qdbus is a regular tool that retains compatibility going forward, like any other tool. That means you should NOT do that strong dependency. app5 should require qdbus >= Qt5, which means Qt 6's should suffice. The only other application that come close are Linguist and Assistant. > ## Binaries that need to be accesible by developers using Qt > > These are moc, rcc, linguist, designer, uic, etc. Some of them really > need to be in > $libexecdir and ought to be found by way of the .cmake and .pc files > [1]. But then > there are the other tools that, once again, need to be readily accesible for > a developer user but in a much "normal" way. Let's say for example > linguist. Translators > are normally more in the "user" side of things than in the "developer" side. > > assistant might probably be in this situation too. > > [1] > <https://lists.qt-project.org/pipermail/development/2018-November/034382.ht > ml> [2] > <https://lists.qt-project.org/pipermail/development/2018-November/034385.ht > ml> > > And maybe lupdate is also an elegible example. The command-line tools used by the build system (moc, rcc, lupdate, etc.) should be in a lib / libexec dir and found by .cmake and .pc files. For a foreign buildsystem, the only modification necessary is to change how it launches the binaries. Not very difficult and probably not the only modification necessary anyway to support Qt 6. Linguist and Assistant are a different story: they should be found by the desktop menu. Both should retain compatibility with old files and, in case of Linguist, *generate* for older formats so the same tool can be used to translate for Qt 3, 4, 5 and 6. Assistant is even worse because it's meant to be launched by applications... That's different from Designer. > # Seeing the problem as a Qt-internal's developer > > I can see value in qtchooser for Qt-internal's developers. You can easily > switch between Qt versions without too much hassle. Not just versions, even different builds of the same version. For the past 7 years, ever since I dropped the 4.8 build, I've only had a single Qt version built. It's built multiple times, with different compilers and options, but it's still the same version. But as you said, this is a developer tool. And interestingly, if we move the developer tools out of $PATH, qtchooser becomes an interesting solution to bring them back in for those few people who want them. So I don't see anything wrong with qtchooser as a developer-of-Qt tool. As a developer-using-Qt, I need to be able to install several Qt in parallel so I can test my application with them, but this is going to depend on which buildsystem I chose for my application. If I'm using qmake, qtchooser is interesting, but people already know to type the full path if they downloaded from qt.io anyway. If I'm using CMake, then I need to set some environment variable so CMake knows where to find the .cmake files -- this isn't solved by qtchooser, but by a wrapping shell function. Additionally, I may want to run a few debugging helpers, like qtplugininfo or qtdiag. > I sincerely do not know how you manage to keep up with your desktop > environment in Linux as I'm pretty sure most of you are not using a > GTK-based desktop :-) Why I say that? because even the smallest Qt-based > desktop environment ships theming which requires using Qt's private API, so > it's tightly tied to a specific ¡minor! version. And I'm pretty sure there > are other cases which have the same issue. My Linux desktop uses the distro-provided Qt. My own builds use a lib infix so that no system application attempts to load my binary-incompatible builds anyway. > # Proposed solution > > All user-facing binaries that do not really belong to $libexec should be > suffixed, as explained in > <https://lists.qt-project.org/pipermail/development/2018-November/034386.ht > ml> Exception: tools that by themselves promise behaviour compatibility. See above. What tools remain as user-facing that are suffixed? Maybe qtdiag and qmake? > - For integrators it will mean easily-deployable solutions without hacks. > > - For Qt-internal's developers will certainly not affect them much once they > get used to the switch (yes, I understand a change sometimes brings > discomfort). See the qtchooser part above as a solution for this. Or they can just add the $libexecdir to their $PATH and we can have symlinks to the non-suffixed versions there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
