[Development] Qt 6 co-installability with Qt 5

Lisandro Damián Nicanor Pérez Meyer perezmeyer at gmail.com
Wed Nov 18 00:41:10 CET 2020


On Tue, 17 Nov 2020 at 14:09, Thiago Macieira <thiago.macieira at intel.com> wrote:
>
> On Tuesday, 27 October 2020 09:34:44 PST Thiago Macieira wrote:
> > Have we fixed it?
> >
> > I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any
> > binary with the same name as Qt 5 did.
>
> Lars and I just had a quick discussion on IRC about this and here's what we
> propose. Ground rules and caveats:
>
> 1) MOST tools do not need to be in $PATH for most users. We developers are not
> most users. For us, setting PATH is acceptable. We're also likely the only
> audience to have more than one 5.x or 6.x Qt version installed.
>
> 2) This recommendation need not be supported by the buildsystem in time for
> 6.0.0, but needs to be as early as possible and by 6.1 at the latest. This
> recommendation allows Linux distributions to apply workarounds meanwhile,
> other buildsystems to adjust (read: Meson), and for us to write docs and QUIP.
>
> 3) there's a question of cross-compilation relating to qmake and host tools,
> which I have not followed and do not understand the current state of. Need
> input here.
>
> With that in mind, our recommendation is as follows:
>
> a) ALL tools be installed to a binary directory that is not $prefix/bin
> b) SOME tools be symlinked/hardlinked/stubbed into $prefix/bin, with a suffix
>   (we recommend a simple "6" instead of "-qt6")
> c) ADDITIONALLY, some further tools can be present unsuffixed
>
> The question is what tools are those in lists (b) and (c). Starting with the
> easiest (c):
>  - linguist
>  - qdbus
>  - qdbusviewer
>
> Those are user-facing tools that definitely do not depend on Qt version. It's
> up to the implementer to decide which Qt version they want these tools to be
> and any choice is fine. My guess is that for two of the three, it will depend
> mostly on Look-and-Feel with the desktop. But since these are an implementer's
> choice, Qt installation never installs those tools with the unsuffixed names
> by default.

Agreed to all above.

> 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])
>  qml6           I don't understand why, but I'm told it's necessary
>  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

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.



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


More information about the Development mailing list