[Development] Proposing CMake as build tool for Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

On Thu, 13 Jun 2019 at 17:02, Thiago Macieira <thiago.macieira at intel.com> wrote:
>
> 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.

That's my perception too, but I don't have data except maybe for some
partial data from linux distributions to back it up.

<side note> it would be at very least amusing to have a guesstimate of
that, but I don't think that's feasible at all.</side note>

> > 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.

Actually they are the worsts examples. Those are the only tools that
it's maintainer (you Thiago) publicly expressed that they will keep
compatibility when I asked about that back when qtchooser was a new
thing. For the rest, at least in my memory (anyone please feel free to
prove me wrong) no compatibility was promised nor denied.

> That means you
> should NOT do that strong dependency. app5 should require qdbus >= Qt5, which
> means Qt 6's should suffice.

Except you can't ship both version in the same binary-package, so
there is no way to express that relationship *with versioning*. The
package will need to depend upon qdbus (qt4) or qdbus-qt5. A virtual
package might be considered, but only for applications that will not
change their backwards behavior *ever*.

> The only other application that come close are Linguist and Assistant.

Ideally we should list all the applications and check whether they
really need to be in $libexec or directly accessible in $PATH, at very
least for the exercise of doing it.

> > ## 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.

As a start of the exercise I wrote above: should lupdate be in
$libexec? lupdate is normally used during string freeze. Granted, it
can be added as a non-automatic target of the build system, but it's
not strange at all to run it by hand. After all, is there any benefit
of running it during the build? Maybe there are some special cases,
but mostly it will regenerate a file that ought to be shipped with the
source code tarball, if shipped at all (I doubt proprietary apps/libs
would ship them).

Also, can we warrant that lupdate will *never* change it's default
output? Maybe we can for qt6, maybe it's a good time to change
something.

> 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.

Agreed for stuff that can really live in $libexec.

> 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.

Just as long as this can be achieved/supported as a P1 bug if it
doesn't. Else we are better off suffixing them. Maybe it's even simple
to maintain.

> Assistant is even worse because it's meant to
> be launched by applications...
>
> That's different from Designer.

Designer needs to be able to load plugins which might come from
different Qt versions, indeed.

> > # 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.

Neither I. Actually I would love to keep it around for this use cases
if deemed useful.

> 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.

Great to know, thanks!

> > # 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.

On Debian/Ubuntu we can even use a tool we have (I don't remember it's
name now, I never used it in my packages) so that if qtchooser is
installed on a system then the binaries in /usr/bin can be replaced
with it. So if people install qtchooser they should know what they are
doing.