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

[Thiago Macieira]

On Tuesday 20 January 2015 04:05:20 Kevin Kofler wrote:
> 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.

I'm agreeing with Kevin here.

We were trying to solve the distro problems back in 2012. If we were trying to 
keep ourselves happy, we didn't have to do anything. Every single one of us 
developing Qt already had scripts to update the environment to target one Qt 
or another. In fact, I wouldn't be surprised if most devs in the Oslo office 
don't still keep the old 15-year-old qset function.

No, we were trying to create one environment to rule them all: something that 
worked for us developers, for our official binaries on Linux, possibly on OS X 
and Windows too, as well as for the Linux distros. Other buildsystems would be 
created to address this environment, so we had to come up with a single 
recommendation for them.

When you say that distros should have just come up with a solution by 
themselves, you're forgetting one important detail: our binaries for Linux. If 
we wanted to let distros come up with a solution, we'd have to adapt our 
binaries too. If they thought the best solution was renaming, we'd have to do 
it too. 

Oh, and update the documentation to say that you'd run "qmake" on Windows and 
OS X but "qmake-qt5" on Linux. Oops, no, only when on Linux and targeting 
Linux, because if you're cross-compiling to QNX on Linux, it's also "qmake".

Ugh, no.

So no, don't tell us qtchooser is not meant to solve distros' problems. It's 
meant exactly for them.

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

I agree with the statement that the developers using multiple versions are the 
minority, but I disagree that most users are just people who want to compile 
other people's software. That's also not true. Those people are also the 
minority: distro packagers and users of build-from-source distros. The 
majority of people who ever run qmake are people who are developing their own 
software, against one single Qt version.

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

I'm going to guess this varies with time. The number of programs targetting 
both Qt N and Qt N+1 is highest close to N+1's first release, then diminishes 
over time as Qt N becomes old news.

That means we have to support both use-cases: targetting one only and 
targetting multiple.

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

To be clear: Ossi was talking about development files and tools, not about the 
libraries. And also note he's referring to another self-made problem of not 
allowing binaries outside of /usr/bin.

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

Indeed, but the Qt devs' original proposal was to simply put it outside 
/usr/bin, possibly even outside of $PATH. If distros had accepted to install 
Qt in (say) /opt/qt5, there would have been no qtchooser, no renaming and no 
need for change anywhere in our buildsystem. But distros refused to do what we 
asked...

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

This statement is easily disproven: I don't change my $PATH on OS X. Not even 
to change between one of three Qt builds I usually carry (with frameworks, 
without frameworks and the ICC build).

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

If the Qt Project now wants to change its recommendation, I won't oppose.

Just to be clear: allowing the distros to rename means updating our Linux 
binaries and documentation too, plus updating Qt Creator to find and run the 
renamed binary.

> > i consider this discussion closed, including for qt6.

You don't get to decide that. First of all, you can't tell what the 
environment for Qt 6 will be.

Second, for Qt 5 the discussion can be reopened if there's new, relevant fact. 
Like, for example, two years worth of experience with the current solution.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center