[Qt-creator] Refactoring the CMake plugin

[Benjamin Zeller]

Am 19.06.2014 00:13, schrieb Miller Henry:
> 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.
Thats almost what my current patch is doing, it runs cmake in the
background when you change
configurations, always,  without popping up the dialog.
If you want to change arguments you can do so in the build settings.
CMake will then
be run automatically in the background when you leave the lineedit you
changed your settings in.
However this does create files without notice which is really a problem
when for example you change
the builddir many times, you might end up with n buildfolders on your
harddisk.

I think it would probably be possible to run cmake automatically when
you finished editing a cmake
file, because in that case you did not change any builddir settings. You
can again say that there might
be cases when new files are created on the harddisk, but only in the
builddirectory you specified anyway
so I think that should be acceptable, right?
>
> 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.
Hm i wonder if cmake has some embeddable tool we could use for that.
>
> 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.
Also almost what the patch does, but what will not work of course is
when you open the project for the
first time and the project file is invalid, then you will only see the
"root" project file.
Once the project is open it will not remove the files from the tree when
you somehow change your
project file and add a error to it.
>
> -----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