[Qt-creator] Refactoring the CMake plugin

Benjamin Zeller benjamin.zeller at canonical.com
Wed Jun 18 12:38:56 CEST 2014


Hello,

I'm working on up-streaming the changes I made on the CMake plugin
for the Ubuntu SDK, this all slowed down in the last weeks because
I was really busy with other tasks.

https://codereview.qt-project.org/80708
https://codereview.qt-project.org/80709
https://codereview.qt-project.org/80710

These are the merge requests, but they still have lots of comments about
how things should be done and unrelated changes ,which made me wonder
if it would be better to start over and get a set of clean patches.

But before I start doing that I would like to discuss how the plugin
should work
and how it should be implemented.

There are 3 features I would like to get into the CMake plugin:

1) Registering new cmake instances / tools

     The idea is to provide a way for plugins to register their own
cmake installation
     and I introduced a class called CMakeManager that will own all
registered installations.
     Every registered cmake will be represented by a CMakeTool instance,
that abstracts away
     how a specific cmake is invoked.
    
     To register them I can see 2 ways:

     a) using factories:
     Personally I like factories more, maybe the approach used by
     the toolchains would fit here too (QList<CMakeTool*>
Factory::autoDetect()).
     That would also require a UI in the settings dialog where the user
can manage the
     available cmake tools and manually register them.

     b) provide a function called registerCMakeTool() in the
CMakeManager that can
     be called by plugins.

2) Associating a cmake tool with a build

     Now that there is a way to have more than one possible cmake, there
needs to
     be a way to control which cmake is used when building/creating the
project files.
  
     a) By linking it to a Kit
         -> provide a CMakeKitInformation so the user can control which
Kit uses which
         cmake tool

     b) By linking it to a build configuration
        -> a CMakeBuildConfiguration would either need to return a
Core::Id specifying the
        cmake tool it wants to use, or the CMakeTool instance itself, so
the IDE can use it
        to create the build files. The build configurations config
widget then can provide a
        way for the user to switch between the cmake installations
available.

3) Automatically running cmake in the background (Get rid of the "Run
cmake" dialog)

     It would be nice if the user was not required to handle the cmake
dialog
     every time he wants to change the build settings, cmake arguments
or wants to
     switch between different build configurations.

     In my MR, a cmake run is automatically started every time the build
     settings are changed and when opening a unconfigured project the
project
     configuration page is used. At first sight this is very similar to
how qmake behaves and makes it easily
     possible to switch between multiple build configurations without
the need for running
     the cmake dialog every time. But the difference of course is that
there are files created when running cmake
     and the user does probably not know about that.

     --> A possible solution to this would be to open a dialog to change
the build settings, but to
     run cmake automatically when switching between build
configurations. This would make the user more aware of what
     is happening.

So if anyone has some thoughts or comments about that, I really would
appreciate the help :).

Thanks,

Benjamin




More information about the Qt-creator mailing list