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

Timo Jyrinki timo.jyrinki at gmail.com
Wed Jan 21 18:22:53 CET 2015


2015-01-20 19:59 GMT+02:00 Kevin Kofler <kevin.kofler at chello.at>:
> scheme.) Debian is now using qtchooser. (But have they ever shipped a
> "qmake5" to begin with?)

The original packaging used the -qt5 suffix but it was dropped [1] in
favor of the recommended qtchooser before uploading the first Qt 5
version to Debian or Ubuntu. Qt 4 was first modified to use qtchooser
so that both could be co-installed.

[1] http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/commit/?id=1c9f8be04f4d30a9ea6c1bdaa6be1dbbe4b8fed5

qtchooser nowadays works adequately with fallback handling and other
workarounds. Ubuntu is also shipping a patch that is not accepted by
upstream [2] as we wanted to offer environment variable / parameter /
default configuration free working of the "user" (developer user)
tools. Upstream considers all qtchooser handled binaries as strictly
development tools, so there is a different point of view there too.

[2] https://codereview.qt-project.org/#/c/82702/

So yes, it's a patch upon a patch solution. It still causes confusion
for random developers that happen to use command line and are not yet
familiar with qtchooser. But they do learn, and a majority of at least
app developers probably install the SDK / Qt Creator and are not
affected.

On the plus side, I like the shorter non-suffix binary names, and the
fact that a default or non-default can be easily set. On the negative
side, not having anything set gives a far from optimal newbie
experience. Because of that for example installing the Ubuntu SDK sets
Qt 5 as the default configuration for qtchooser. I don't have a strong
opinion, but it needs to be all platforms or nothing. Otherwise
cross-platform developers and documentation just get confused.

-Timo



More information about the Development mailing list