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

[Thiago Macieira]

On Sunday 18 January 2015 02:29:14 Kevin Kofler wrote:
> > Because it also works for those of us who have multiple Qt 5 builds. I can
> > run:
> > qmake -qt5
> > qmake -qt5-release
> > qmake -qt5-icc
> > qmake -qt5-clang
> > qmake -qt5-mips
> > qmake -qt5-static
> > qmake -qt5.1
> 
> Well, you could install all those as suffixed versions without the space,
> or  just run them from their specific bin directories.

That doesn't take into account the selection done by an environment variable. 
Using QT_SELECT rather than PATH is just for simplicity. It's a lot easier to 
switch from "5" to "5.1" by setting a full variable (overriding any previous 
values) than finding the previous path in PATH, removing it, and prepending the 
new one. My pre-qtchooser shell functions did that and very often I would find 
after weeks of work that PATH contained 10 different Qt builds.

> And to be honest, this is not really a use case we care about in 
> distributions (at least not in Fedora):

Your other email indicates otherwise. There is one case you care about: 32- vs 
64-bit builds of the same arch. See the other email for a discussion of this 
and future work.

Also, maybe you don't care about this officially, but Fedora does have MinGW 
packages for Qt 5, so there are at least 4 possible, different Qt 5 builds one 
may want to target.

> > What's more, by setting QT_SELECT, I can change the default, without
> > having to fiddle with PATH.
> 
> So you set one environment variable instead of another? Was that really 
> worth the effort of writing those wrappers?

Almost. There's more, but see above why this is almost enough.

> >> This will never be reconsidered. It would break backwards compatibility
> >> with our existing releases.
> >
> > 
> >
> > How?
> >
> > 
> >
> > You can keep the default as is, so no one will know that the default qmake
> > is now qtchooser. But you will support the standardised way.
> 
> All Qt 3 programs will break.

How?

If you leave qmake pointing to Qt 3's qmake by default, they won't be able to 
tell. Now, this isn't what we recommend (we recommend Qt 4 as the default), 
but it's an acceptable compromise. Most build scripts that run qmake and 
require Qt 4 end up trying the non-standard qmake-qt4, so they won't break 
either.

What's important is that Qt 5 build scripts can rely on "qmake -qt5", with the 
space.

> Why won't you consider the solution I proposed? (Ship both qmake, uic, moc 
> etc. AND qmake-qt5, uic-qt5, moc-qt5 etc. 

Reasons:

- "etc" = 37 different binaries
- inserting the argv check for the warning, as you suggest, in each of them is 
  work we'd rather not have and also which can go subtly wrong due to bad copy 
  & pasting
- the current solution is much simpler
- it was agreed upon in 2011
- and...

> in Qt 5.5, document the former as 
> deprecated in favor of the latter, also deprecate qtchooser. Eventually
> drop the unsuffixed versions in Qt 6.0, shipping only -qt6 ones. The result
> would be that programs still using Qt up to 4 would be no worse off than
> they are right now, programs using Qt 5 would be able to migrate to the now
> officially supported suffixed binaries (and if they don't, they would be no
> worse off than they are right now either), and for Qt 6 and later, the
> issue would be resolved once and for all, there would be one standard
> binary name to invoke: the suffixed one.)

...because scripts that used to work with Qt 4 and Qt 5 should not have to 
change "moc" to "moc-qt6". We're trying to retain compatibility. Renaming 
tools does not read "compatibility".

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