Hi Benjamin, I see no reason not to do that in the KitConfigWidget. I do not expect this to change often enough to warrant not simply re-running the detection step whenever a executable is set that looks like a cmake. You need to validate the kit configuration anyway, independently of whether or not you have a separate cmake page or not.
What information would go on the cmake-management page? Just a list view of known cmakes and a lineedit to show the path of the currently selected one? That seems a bit too little information to warrant a separate page to me. Qt versions do have a lot more state, so do the toolchains. I also expect users to have lot of Qt versions and toolchains, and to switch between them on a regular basis. I do not see any of this for cmake. Of course that might be only because I have not used cmake in earnest in a long time. I definitely see that we should support Mathias' use-case, but having a cmake binary in a kit should cover that nicely. Of course you have a somewhat different use-case in ubuntu with the one-cmake-per-chroot approach. But even there the chroot is the thing you want to switch and not the cmake binary: That is just a means to the end. I would personally expect some ubuntu-specific page that helps users register/deregister and manage their target environments. That should of course manage the kits associated with those target environments. Each kit can of course include the appropriate cmake binary if that is necessary. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company 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 Email: [email protected] | Phone: +49 30 63 92 3255 www.qt.io | Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt On Di, Jan 27, 2015 at 4:33 , Benjamin Zeller <[email protected]> wrote: > Am 27.01.2015 um 16:26 schrieb Tobias Hunger: >> Hi Mathias, >> >> ok, I see that use-case, but I do not see why cmake needs an options >> page of its own. >> >> I still think Just adding the path to the right cmake binary to the >> kit would suffice. > In fact, I thought about this. But QtCreator needs to run detection > code for every cmake instance. Like supported generators and so > on. > If the Kits just have a path instead of a central registry like the > toolchains > when and how should this code be executed? >> >> Best Regards, >> Tobias >> >> On Tue, Jan 27, 2015 at 4:16 PM, Mathias Hasselmann >> <[email protected]> wrote: >>> >>> Am 27.01.2015 um 15:27 schrieb Daniel Teske: >>>>> its been a while since we last merged the upstream CMake plugin >>>>> into our own Ubuntu-SDK codebase. As a result our current version >>>>> is behind the most recent QtC release. >>>>> Since the last merge there were a lot of things changed in the >>>>> plugin >>>>> that makes it almost impossible to merge it again, so we decided >>>>> to >>>>> start from scratch and since we have learned from the last time >>>>> we >>>>> want to first propose the refactoring steps we are going to work >>>>> on. >>>>> >>>>> We decided to drop the idea of removing the "Run cmake" dialog >>>>> but >>>>> still need a possibility to have a cmake per Kit. >>>>> >>>>> So here are the steps, each one would be a self contained patch: >>>>> >>>>> Patch 1: >>>>> -> Add a view to register multiple cmake instances to the system >>>>> (in >>>>> tools->options->Build&Run->cmake) >>>>> * The user can select a default cmake tool that will >>>>> be used for >>>>> every build >>>>> * do not add it to the Kit yet to keep the patch small >>>>> * use a view like in the QtVersions settings page >>>>> (treeview) >>>>> * provide a central registry for all the cmake >>>>> instances >>>>> (CMakeToolManager) >>>>> >>>>> Patch 2: >>>>> -> Make the cmake instances known to the Kits >>>>> (CMakeKitInformation) >>>>> * The run cmake dialog will pick up the cmake from the >>>>> kit >>>>> >>>>> Patch 1 is rather big, but I do not see a way to break it down >>>>> even >>>>> more, but >>>>> I'm open for suggestions :). >>>>> >>>>> Daniel, can you please tell me if this proposal as the base of >>>>> our >>>>> implementation >>>>> is acceptable for you? >>>> So I have only limited understanding of your setup and needs, >>>> thus I can only >>>> comment on this in isolation. There have been some people wanting >>>> to have >>>> multiple different cmake executables, but that's a fringe use >>>> case as far as >>>> I'm concerned. >>> That's not too fringe in my opinion: I regularly encounter the >>> situation >>> that I'd need cmake 3.0 or even master for experimental or new >>> project, >>> while having to stay with 2.8.12 (or even older) for customer >>> projects. >>> Sucks to leave QtCreator in those scenarios. For CMake there really >>> should be different versions supported. Just as for compilers and >>> for Qt >>> versions. >>> >>> Ciao, >>> Mathias >>> _______________________________________________ >>> Qt-creator mailing list >>> [email protected] >>> http://lists.qt-project.org/mailman/listinfo/qt-creator >> _______________________________________________ >> Qt-creator mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/qt-creator > > _______________________________________________ > Qt-creator mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/qt-creator _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
