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