[Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi Lars!

On Wed, 18 Nov 2020 at 08:03, Lars Knoll <lars.knoll at qt.io> wrote:
[snip]
> Thinking a bit more about this, I wonder how many applications _really_ need a version.
>
> To start with, I think it’s important to recognise a difference between developer oriented tools and tools targeting end users.
>
> Most of our developer oriented tools are (or can be) dependent on the exact version of Qt installed. Thus the problem is larger than just a Qt 5 vs Qt 6 thing.
>
> Those tools should just stay in a version specific directory and should IMO not be exposed in the generic path for end users (moc should for example never end up in /usr/bin). Instead the correct version is found by the build system and called from there. And developers needing direct access to them should adjust their path to include those tools.

Well, that's a huge change from what was discussed before, specially
when I brought this topic in Qt 5.0 (which I had forgotten, Thiago
made me remember). Yes, of course, if we can decide that most of the
tools are for developers only and can live outside $prefix/bin then
it's definitely another way to solve this issue. And in fact it might
be a much better solution.

So basically:

- Move out of $prefix/bin (and thus out of $PATH) every developer-oriented tool.
- Ensure that user-facing applications will be backwards compatible
with Qt 5 for all the Qt 6 timeline.

> For most end user facing tools, I wonder whether we actually need to support co-installation. The examples listed just below (linguist etc.) are backwards compatible, and it should be ok to simply install the latest version, similar to what is done with qtcreator.

Yes if backwards compatibility is assured. Last time we discussed this
(for 5.0 if my memory does not fails me) designer was considered a
tool that needed to be on $PATH. When Qt5's designer arrived it
supported Qt4's plugins... for some time.

But then I wonder if designer shouldn't stay on $PATH or not. Because
even if it's a developer tool it's one expected to be on $PATH much
like Qt Creator. The developer tools that can stay out of $PATH are
the ones that can be easily callable from within toolchains (qmake,
cmake, etc). But then again we distros could simply make a
$prefix/bin/designer6 symlink. Telling our users "just use designer6"
it's really not a big deal, even if the docs just say "designer".

[snip]
> Then there's the question of which tools we recommend be in $PATH with a
> suffix (list (b)). Please expand on this list if necessary, with a reason.
> Here's the minimum list:
>
> qmake6         entry point for building qmake-based applications, situation
>                similar to /usr/bin/python (see [1])
>
>
> I am not yet 100% convinced it is. This is a build tool after all, and even changes with minor versions of Qt. I know Linux distributions do only ship one minor version, but many of our users have to manage multiple minor versions of Qt as well. And renaming qmake with every minor version is a no-go.

Well, that's the exact opposite reply I've got (from Ossi?) on Qt 5.0
times. qmake needed to be on path in order to be able to query it for
some paths. But if that's no longer the case then yes, it can stay
away.

> qml6           I don't understand why, but I'm told it's necessary
>
>
> It’s a runtime for running qml files without a C++ entry point. But we can actually decide that this is a developer oriented tool and not have it linked into /usr/bin.

Still a tool that is expected to be called by humans though. And then
again we could easily keep a $prefix/bin/qml6 link.

> qtdiag6        entry point for debugging problems with Qt 6
> qtpaths6       because knowing the path in order to run the tool to get
>                paths sounds weird. Having this in $PATH allows us to
>                help users get to the other, debugging tools (qtplugininfo,
>                qmlplugindump, etc.)
>
> Possibly also:
>
> assistant6     for reading Qt 6 help files when not using Qt Creator
> designer6      for those not using Qt Creator and needing to use Qt 6 plugins
>
>
> Offtopic, but I wonder how much those standalone apps are still being used today.

designer: a lot, specially if your screen does not has enough
resolution to use it embedded within Qt Creator. That's exactly my
case (yes, I sadly still have an old machine, the same I used in Qt
5.0 times ;-) )

> Also agreed. I would consider assistant6 and designer6 to be included
> in list (b) due to past experience.
>
> Tools I don't know if they should or shouldn't be in this list:
>
> - pixeltool: it's a screen magnifier, never used it before, but
> clearly not something used at build time. Sounds like a user-facing
> app for me.
>
> - qtplugininfo: I sincerely don't know how it's being used.
>
> - qtwaylandscanner: same as above.
>
> - tracegen: same as above
>
> - sdpscanner: "Performs an SDP scan on remote device, using the SDP server
> represented by the local Bluetooth device." Sounds like a user-facing app.
>
>
> All of those are developer facing tools and shouldn’t be in /usr/bin at all IMO.

And again, they could be easily symlinked with a prefix if needed.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/