[Development] Qt 6 co-installability with Qt 5

Thiago Macieira thiago.macieira at intel.com
Wed Feb 17 23:39:49 CET 2021

On Wednesday, 17 February 2021 00:32:13 PST Joerg Bornemann wrote:
> Yes, and that's all good, and with
> https://codereview.qt-project.org/c/qt/qtbase/+/334054 we will have an
> offical recommendation.
> I will also add a documentation page in the vicinity of
> https://doc.qt.io/qt-6/linux-building.html

Make that "mac building" too, because it shall apply to Homebrew. Windows has 
no concept of global paths, so it doesn't matter there.

I also think the step should be automatic from the CMake build, instead of an 
optional extra. That will lead to confusion because people will forget and 
then send questions into forums and mailing lists.

> The only thing we're still arguing about is how to call the tools in the
> documentation.

I think we should follow the majority, both in quantity and in volume.

All but one of the binary distributions will rename. That's all the Linux 
distributions, FreeBSD ports tree, Homebrew on Mac, and possibly Conan on 
Windows too.

Therefore, we do request that it be made obvious that it is called "qmake6" 
and "qtdiag6" almost everywhere.

The official build from qt.io, which is much less important these days because 
it can't be anonymously downloaded, can be the odd one out if it wants to. I 
suggest that you do apply the new name there too, but that's your choice. Just 
don't make your minority choice rule the user experience for the majority.

> To mention that the distro-provided qmake might be called qmake6 can
> (and should) also be done. But to change qmake to qmake6 everywhere in
> the docs is as consistent as not doing anything - as long as we don't
> rename the tools.

I agree with the arguments.

Therefore, I come to the conclusion the tools should be renamed.

> Renaming just the three tools you mentioned would be inconsistent.
> Renaming all tools is too late.

No, it isn't. We agreed that 6.1 would be an acceptable target for this 
massive change because we didn't want to risk 6.0, therefore it is acceptable. 
No one is currently using 6.0 because it's incomplete for many applications 
and because it is a dot-zero release.

Also note that the longer those modules go unmaintained, the bigger the chance 
people will simply begin porting away from Qt entirely. I've already been 
asked that question inside Intel: projects that were on the last LTS (5.12) 
are trying to figure out their futures.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

More information about the Development mailing list