[Qt-creator] Refactoring the CMake plugin

[Hunger Tobias]

Hi Benjamin,

On 18.06.2014 12:39, Benjamin Zeller wrote:
> 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

I did not read those, so my comments are entirely based on the contents 
of this mail.

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

Why do you need all that? Why doesn't a simple path to the executable 
suffice? That executable may very well be a script if that is necessary.

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

I'd say the kit is the way to go here. We created kits to get this 
repetitive configuration out of individual build configurations into one 
central place.

I would personally just add a CMakeKitInformation with the path to the 
cmake binary you need to call. No CMakeManager, no CMakeTool, nothing:-)

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

I am not sure I like this.

The Run CMake dialog makes it clear that we are going to write something 
to disk. There is just no way to run cmake that does not write something 
somewhere.

We generally try to avoid writing files in places where that is not 
expected. If a user e.g. changes the build dir 100 times in Project mode 
between builds, then he should only see the 100th directory that is 
selected when he hits build, not the 99 directories before that.

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

IMHO that is a no-go: The user does not ever get a chance to change the 
build location before you pollute his drive then.

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


I personally would not be opposed to not having the cmake dialog when 
switching back to an already configured build configuration with an 
already existing build directory.

But then I am not the cmake maintainer and am not fully familiar with 
the code base nor the direction it is supposed to take.

Best Regards,
Tobias