[Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1

[Frederik Gladhorn]

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
> > awkward
> > position, and need to install an extra copy of Qt Creator (see
> > below)
> 
> 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
> up.
> 

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

Cheers,
Frederik


> 
> 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.
> 
> 
> Regards
> 
> Kai
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development