[Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Wednesday, 18 November 2020 04:34:40 PST Lisandro Damián Nicanor Pérez > 
> 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.

I don't think that will work for qmake6 (see below). I am willing to accept 
this for all other (developer) tools. 

As for user-facing, here's the litmus test: the application can be moved out 
of the Qt repositories into one of its own. And then we do exactly that. 
Preferably also removing the use of private API in the process.

We've long had the question about translators wanting to install Linguist, but 
the only installation we have of it is the full Qt, which requires a compiler 
to also be present. Instead, we should provide translators with an installable 
Linguist using the Installer Framework for Windows, a macdeployqt bundle in a 
.dmg for Macs and, if we're feeling adventurous, a FlatPak for Linux.

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

That's not an option. The docs must say either:
a) "run designer6"
or 
b) "run <QTDIR>/bin/designer"

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

qmake6 needs to be on PATH because that's how we will tell people how to build 
their applications. Telling users to go discover where their Linux 
distributions installed Qt6 is not acceptable, in my point of view.

In any case, since we *need* qtdiag6 and qtpaths6, I don't see what's the harm 
in having qmake6 too.

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

I don't care enough. I'm sure I haven't run this tool in 3 years. I even 
thought "qmlscene" was the one we were supposed to run since 5.0...

I'm just following what has been said in this thread that some people do run 
it.

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

I'd like to come to a consensus so that every installation follows procedure 
and is supported by docs. I'd rather Linux distributions didn't feel the need 
to start adding more symlinks.

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