[Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1
Eike.Ziller at digia.com
Mon Jul 7 12:02:55 CEST 2014
On Jul 7, 2014, at 11:17 AM, Frederik Gladhorn <frederik.gladhorn at digia.com> wrote:
> Mandag 7. juli 2014 07.10.00 skrev Koehne Kai:
>>> -----Original Message-----
>>> From: development-bounces+kai.koehne=digia.com at qt-project.org
>>> 1) Developers who face regressions (not just testers) are now in an
>>> position, and need to install an extra copy of Qt Creator (see
>> Right, that's the main drawback. We could maybe have a 'Show all' section in
>> the settings dialog or so that would show/hide such patch level releases
>> though ... will bring this up with the Release Team.
>>> 2) In Qt Creator, the Qt version and kit are still listed as "Qt 5.3.0",
>>> even though it has been upgraded to Qt 5.3.1. Since it is an
>>> auto-detected entry, the user cannot change the name.
>> Yeah, that's something we should fix in the next Qt Creator release.
>>>> Is it possible to use the offline installer to install 5.3.0 into the
>>>> existing installation and not install a new Qt Creator?
>>> No. When running an installer (online or offline), Qt Creator is a
>>> compulsory component (although Qt itself is non-compulsory). I remember
>>> someone saying that Qt Creator is made compulsory because of
>>> interdependencies between the Maintenance Tool and Qt Creator.
>>> What are these dependencies? I'm willing to have a go at reducing this
>>> coupling, if I know where to look. I believe one of them is for the
>>> installer to register "auto-detected" kits. Instead of having the
>>> installer perform this registration, would it make sense for it to simply
>>> add a "search path" to a global Qt Creator config file, and let Qt
>>> Creator search for and register new copies of Qt at startup?
>> Registration of Qt versions, kits, and toolchains is indeed the primary
>> problem. We call Qt Creator's sdktool.exe in the
>> installation/deinstallation scripts of the Qt versions & the mingw
>> toolchains .
>> I'm not sure doing too much (file system) magic on Qt Creator startup
>> though is the right thing to do, since it will slow down every launch.
>> Alternatives that have been discussed in the past:
>> 1. Move the sdktool.exe out of the Qt Creator package, into a separate one,
>> and only make this one mandatory. That means though we'd need to ship
>> separate Qt libraries for this tool only, effectively increasing the size
>> of a 'default' installation.
>> 2. Don't deregister/register toolchains and kits in the qt packages, but in
>> separate virtual (i.e., hidden) packages that are only installed if both
>> the resp. Qt version package and the Qt Creator package gets installed
>> (AutoDependOn in IFW speak). This will only be a workaround though for new
>> packages ... already released qt versions will still have a hard dependency
>> on Qt Creator.
>> 3. Accept the fact that, if people first install a Qt version / toolchain
>> and _later on_ install Qt Creator, the toolchain & Qt version won't show
> 4. I still think on Windows using the registry would be the way around this.
> On Linux and Mac the respective .config dirs. Python for examples does this on
> installation on Windows and can then be found by looking it up in the
> This solution is imho portable and allows all Qt versions to be found by all
> Creator instances as well as other tools (qtchooser would be a good candidate
> to make use of the same mechanism).
Since there are no “system wide” config dirs that would mean using something like /etc (/opt ? /usr/local?) on Linux, /Library/Preferences on Mac, and “current_machine” registry on Windows for “system wide” installations, and “.config” on Unix and “current_user” registry on Windows for “user” installations.
That would make things much more complicated, and possibly force that information to be compatible between versions of Qt Creator (it’s btw not only about Qt versions here, also all the other things that are specified for kits).
Also, I currently have 5 offline Qt installers installed simultaneously for testing. Using a “machine/user wide” registration mechanism, instead of an “installation wide” registration mechanism would basically disallow that.
>> I think both 1. and 2. are be feasible ... 3. might end up in more bug
>> reports / annoyed users than the current 'forced' installation, so I'm
>> personally not keen to implement this.
>> Development mailing list
>> Development at qt-project.org
> Development mailing list
> Development at qt-project.org
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
More information about the Development