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
