[Development] Proposing CMake as build tool for Qt 6

[Thiago Macieira]

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