> -----Original Message----- > From: [email protected] > [...] > 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. 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 [email protected] http://lists.qt-project.org/mailman/listinfo/development
