[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Kevin Kofler]

Oswald Buddenhagen wrote:
> correct. as far as i'm concerned, the purpose of qtchooser is to be a
> frontend tool which targets developers working with multiple qt
> versions, regardless whether these versions come from distro packages or
> own builds.

The thing is, we asked for something that fulfills distro's needs. You shot 
that down and instead got Thiago to implement something different. And now 
you say yourself that it is not what was asked for.

Developers working with multiple versions of Qt 5 are by far the minority. 
Most users of Qt development packages actually just want to compile software 
somebody else wrote. And even those that actually are developers are usually 
happy with our regularly-updated builds of the latest stable Qt release. To 
all those users, different major versions are the ONLY coinstallation case 
that matters.

> build systems which target specific (major) qt versions are simply out of
> scope.

Says who? That is by far the common case. Very few programs support more 
than one major version of Qt.

> your problem is a self-made one: the attempt to co-install major
> versions of everything.

As long as there are new major versions of Qt (i.e., new versions that are 
not 100% drop-in replacements for the previous version), there WILL be a 
need for coinstallation. Programs do not magically port themselves 
instantly. Even the upstream developers themselves need time to port things. 
Distribution packagers are usually not qualified to do such a port, so we 
need to wait for upstream to do it (and even if we were to attempt porting 
the software ourselves, it would probably take even longer). And then, as I 
wrote in the first paragraph, there is also software compiled by end users 
on their own. And finally, there is some software that never gets ported. It 
is stuck on an obsolete Qt version, but it works and is useful to our users, 
so dropping it would be a disservice to our users.

So, as Sune Vuorela also explained, having multiple major versions of Qt in 
parallel is always going to be a fact of life.

> this is a linux distro specific problem,

Only because we are the only operating system to actually support building 
software without messing with path settings all over the place.

I'll also add that even for those operating systems (such as Windows) where 
you do have to tweak PATH, having non-conflicting executable names allows 
setting the PATH once in the user-wide or system-wide settings in the 
control panel and not having to run a setpaths.bat once for every single 
build.

> and demanding x-platform upstreams to accept trade-offs to adjust to it is
> *unreasonable*.

What trade-offs do they have to accept? They just need to add "-qt5" to the 
name of the binary / .EXE file / whatever that they run in their build 
scripts, once. (And only if they do not simply use a third-party build tool 
that does the right thing for them already.) In exchange, the program will 
always compile fine even if there is also a Qt 4 in the systemwide PATH, a 
situation that can occur on ALL operating systems (including ones not 
supported by qtchooser), as I explained.

> now, you will say that most users under linux use qt via distro
> packages. that's right. and you know what? it's *your* task to make it
> work for them.

And we are. But Thiago is complaining about it.

> if upstreams of qt-using applications choose to support distro-packaged
> qt (via having preference lists of suffixed qmakes, for example), that's
> a perfectly reasonable thing to do. if distros among themselves want to
> standardize on a pattern to ease this, i'm all for it. it's still not
> something *we* (qt upstream) need to be concerned with.

Now this is really funny. We wanted to do the renaming upstream. You were 
one of those people who shot it down. Now you are saying we should just do 
it downstream. On the other hand, Thiago also wanted to do the renaming 
upstream, he was told not to, so he implemented qtchooser instead, and now 
says that everybody should use qtchooser and that anything else is broken.

Since it is clear even to you that qtchooser is not what we want, why did 
you force Thiago to implement it, and why are you still not willing to allow 
the proper solution to be implemented upstream?

I'll also point out that, while Debian currently does use qtchooser by 
default, Lisandro from Debian also stated that he would prefer suffixed 
binaries. I am not sure there is even ONE distro that is happy with 
qtchooser.

> i consider this discussion closed, including for qt6.

And I think that this is a mistake. There is a real problem here, one that 
affects ALL your downstreams (not just GNU/Linux distributions). In Qt 4, 
upstream's answer was to ignore the issue. In Qt 5, qtchooser was 
introduced, which solves a different problem from the one we are having 
(namely, letting the USER choose between different Qt versions that ARE 
drop-in replacements, i.e., different variants of the same major version). 
Coaxing it into solving our problem introduces more issues than it solves. 
Why can we not finally get the right thing to happen for Qt 6, or even (with 
the soft migration path I described elsewhere in this thread) upcoming Qt 
5.n releases? The right thing can be done, see e.g. KF5.

        Kevin Kofler