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

[Thiago Macieira]

On Monday 19 January 2015 00:16:48 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > Because we're in 2014. Qt 4.0 was released in 2005 and the binary wasn't
> > renamed. Software is supposed to work with the official version too and
> > there are 9 years of history of us releasing "qmake".
> > 
> > Therefore, that buildsystem needs to try qmake alone.
> 
> The point is, try qmake-qt4 first, and if it doesn't exist, try just qmake.
> That will work in all cases, and does not need test-running anything, only
> checking existence.

That logic is inverted. It needs to try qmake first because it might be a more 
recent version, installed by a binary from the Qt Project, since we don't 
rename. Any qmake-qt4 tool, if present, is an older version from the 
distribution.

> > I'm ignoring qmake-qt5 because it's totally non-standard.
> 
> It is only "non-standard" because you (Qt upstream) refused to settle on the
> convention almost every distribution in the world has been successfully
> using for years (for Qt 4). (I know that at least Fedora, RHEL and
> derivatives, Debian and Mandriva used -qt4 suffixes at some point. There
> were probably several more. Some of them, like Debian, dropped the suffixes
> as a result of dropping Qt 3.) So YOU created the mess where we now have 2
> competing approaches. We only decided to stick to the standard that has
> worked for years.

There was no convention about Qt 5 prior to the Qt 5 launch. I described how 
this solution would have worked if you guys hadn't created the problem.

> > But yes, they need to run things. How is that different from running
> > pkg-config? Or running mysql_config?
> 
> That is not a "try to run something and catch the error" approach. Approach
> which also assumes that you get an error to begin with, and the unhandled
> argument is not silently misinterpreted as meaning something completely
> different.

I don't see how it could be silently misinterpreted. qmake from Qt 4 does not 
handle an argument of "-qt5", so it will fail to run. You can catch that 
situation just the same way as you'd catch a "pkg-config --cflags Qt5Core".

> > That check is irrelevant.
> > 
> > You either run a full path to moc, which you obtained from qtchooser or
> > qmake, or you run "moc -qt5". Any of those three are going to successfully
> > run the Qt 5 moc if it's there or it's going to fail.
> 
> The tool can always be in the default path.

True, but any decent buildsystem would be adapted to the case when it isn't, 
in which case it gets the full path and uses that.

> > Which should be zero. All systems should use qtchooser, except Windows.
> 
> Yet even the tool's own documentation explicitly claims that it is also not
> for OS X.

It works fine on OS X. I use it there.

It just happens that most OS X users don't need it because they don't put Qt 
in PATH. They only use it via Qt Creator or by running qmake with full path to 
create an XCode project.

> And at this point, we really cannot expect qtchooser to "catch on" anymore.
> It is always going to be an obscure hack that only some Qt developers and
> Debian are using. It is time for you to admit that it was a failure, and
> finally ditch it.

Why do you make such a prediction?

> Qtchooser blatantly violates the "KISS" principle. (It is completely
> overengineered.) It also introduces some very nondeterministic behavior,
> such as invoking one and the same executable ending up running a completely
> different binary depending on the contents of a configuration file (!) or an
> envionment variable (!). There is a very simple solution to the problem of
> coexistence of multiple Qt versions: the -qt5 suffix. Your qtchooser
> wrapper is much more complicated and thus much harder to maintain. (Even
> with our only optional support for qtchooser, we ran into several packaging
> issues caused by it. The multilib issue I mentioned was one of them.)

Renaming the tools creates other problems. We needed a compromise and 
qtchooser is it.

> > And like I said, Fedora's and RHEL's refusal to follow the recommendation
> > is their own problem.
> 
> It is also going to be your problem if programs get written for Fedora
> and/or RHEL and thus hardcode qmake-qt5 (which in fact I may well actually
> start RECOMMENDING to developers, to force both other distros and upstream
> to start supporting it). Welcome to the real world!

That won't happen because those applications will get written for the official 
binaries from the Qt Project, which do not contain renamed tools. Do you 
really think people will write software that doesn't compile with the official 
version? Instead, you'll have the burden to keep sending people patches so 
they can be built on your distro.

If we get any issues reported to us about Fedora or RHEL's non-renamed 
binaries, we'll send back to you, with the recommendation that people file bug 
reports about not using qtchooser. I already do that.

Remember: you (implicitly) agreed with the solution in 2012. If you 
unilaterally choose to deviate from it, you should be the one to bear the 
burden.

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