[Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Tuesday, 16 February 2021 05:31:17 PST Kai Köhne wrote:
> Well, let's just realize that, by renaming qmake to qmake6 everywhere
> (including in the documentation), we actually create some confusion for our
> existing users, too. Also, I think adding version numbers to the name of
> tools is just no good user experience, and creates unnecessary friction
> when switching between Qt versions.
 
> To be honest, the whole discussion feels to me that we are being held
> hostage right now for the fraction of Linux users that cannot use
> update-alternatives (because they are not administrators). If having
> different names of tools is such a big problem, why wasn't this addressed
> by now in Linux itself?

It has: by renaming our tools. And note the email from the Homebrew folks 
asking the same question. I suspect it hasn't been a problem for them because 
they don't have a Qt 4 recipe in the first place.

Just look at any project and any third-party documentation on how they try to 
find qmake. They try "qmake-qt5" first, then "qmake".

We're simply asking that we make official what is already done everywhere.
 
> And again, this is not something limited to Qt. Last time I checked, the
> executable to run Python 3 on Windows is python.exe, not python3.exe. On
> Debian at least it's python3. This hasn't blocked Python from being
> perceived as overall beginner friendly ...

All Python3 scripts I've EVER seen start with:
#!/usr/bin/python3
OR
#!/usr/bin/env python3

On Windows, there's no /usr/bin, so that doesn't work anyway. Cygwin/MSYS 
environments that do offer such a mount point also offer Python 3 at 
"python3".

Look also at OUR Python scripts (and by "our" I include any and every one from 
our third-party dependencies). All "#!/usr/bin/python" are Python 2 scripts, 
even if there are a few exceptions like "#!/usr/bin/python2.7", and the 
Python3 scripts use "python3" in the name.

FInally, Python has a recommendation: 
https://www.python.org/dev/peps/pep-0394/

Summary:
/usr/bin/python2 is python 2, if installed
/usr/bin/python3 is python 3, if installed
/usr/bin/python is one of the two above and is optional

I am fine if Qt 6 adopts this recommendation.

But note its conclusions: "qmake' can be Qt 5's and "qmake6" is mandatory. 
Therefore, the documentation MUST mention "qmake6".
 
> So, I would stick to qmake as canonical name, also in the documentation. We
> can mention that it's sometimes called qmake6 on Linux. But forcing
> everyone to change their habit and scripts just for the sake of consistency
> with a fraction of the users that use a global installation on Linux, and
> do not use update-alternatives, is IMO not a good move.

The vast majority of people with scripts for applications that support both Qt 
5 and 6 are developers like us who have more than one environment of Qt and 
therefore will do PATH modification when they switch environments.

There are very, very few real applications that support both and come with 
scripts. The majority of those are actually Qt 4 CMake-based applications 
because Qt 4 didn't have CMake files. And note it does search for "qmake-qt4"
(<https://github.com/Kitware/CMake/blob/master/Modules/FindQt4.cmake#L521>). 
[FindQt.cmake is usually used for Qt 3]

qmake-based applications that support more than one Qt major version are rare. 
Granted, they are more common during the transition period, but since Qt 
Company's decision this time to accelerate transition from 5 to 6, it will be 
less of an impact this time around. Either way, users need to know whether the 
application has been ported to Qt 6 in the first place and the easiest is for 
the authors / maintainers to document that you should use "qmake6 ".

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