[Qt-creator] Refactoring the CMake plugin

Miller Henry MillerHenry at JohnDeere.com
Thu Jun 19 00:13:24 CEST 2014


On question 3:

When switching project configurations, if the build is at all out of date the first thing I'm going to do is re-run make anyway.   The only other option that makes sense it to completely blow away the build directory and re-run cmake.  I would go so far as making it an option to just run a full build anytime I switch my build configuration (default to true as it is what the user wants even though it violates some purists expectation that no files will be written).  I find it very annoying to have this cmake dialog pop up when I open an out of date build, as I'm just going to hit run and wait for it to complete.  So long as no build option is being changed, I want qt creator to write the files it needs and not bother me.

Now if the cmake dialog acted more like ccmake and let me change cached options that might be useful: the only thing valid to do from the cmake dialog in an existing build directory is change options that ccmake could change for you, but since I only have access to the command line of cmake this isn't convenient. I'm not sure if the cmake cache files are in a stable format where it would be valid for qt creator to do this, but it would be ideal.

One annoyance I have is once in a while an automated build fails, when I open qt creator it tries to run cmake, which fails because of a syntax error.  There is no easy way to open the offending file in qt creator so I can fix the error(s).   If you can do something about this I'd be grateful.  At least I'd like it if an outdated project configuration could be used because that will have 95% of what I need.

-----Original Message-----
From: qt-creator-bounces+millerhenry=johndeere.com at qt-project.org [mailto:qt-creator-bounces+millerhenry=johndeere.com at qt-project.org] On Behalf Of Benjamin Zeller
Sent: Wednesday, June 18, 2014 5:39 AM
To: qt-creator at qt-project.org
Subject: [Qt-creator] Refactoring the CMake plugin

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

_______________________________________________
Qt-creator mailing list
Qt-creator at qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator



More information about the Qt-creator mailing list