On 7 July 2014 15:10, Koehne Kai <kai.koe...@digia.com> wrote: >> From: development-bounces+kai.koehne=digia....@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.
Thanks! [...] >> 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. Perhaps Qt Creator could check to see if a path is already in its list of registered versions/kits/tools, before scanning the physical location? > 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. Agreed, #3 sounds like swapping one set of issues for another. #1 makes a lot of sense; sdktool could be considered an inseparable part of the MaintenanceTool. I'm less familiar with #2 as I haven't implemented package managers before; would this option increase the risk of repository corruption? (Example: https://bugreports.qt-project.org/browse/QTIFW-519) Regards, Sze-Howe _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
