[Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 13:45, Thiago Macieira <thiago.macieira at intel.com> wrote:
>
> 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.

That would be simply awesome.

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

In that case I would prefer (a) because it's situation is almost the
same as the qmake one you describe below.

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

Agreed, that's why I followed my initial mail comparing it to CMake,
I've just realized it later.

And I think a tool like designer should follow the same path.

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

Right.