[Qt-creator] Refactoring the CMake plugin

[Benjamin Zeller]

Hi 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.
Well the idea here was to be able to , for example, set different
environment
variables or add cmake arguments on the fly if the specific cmake
version needs that.

I also heard from other people it would be nice if one could configure a
cmake installation for example to add a preload cache script.

Also for example if you want to configure a special toolchain file, or
just for
identifying a special type of cmake in the sourcecode. For example the
ubuntu sdk plugin identifies Ubuntu SDK kits by checking if the cmake
tool is of a special type.
>
>> 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:-)
Hm interesting, so we need at least a "default" cmake but that can still be
the one found in PATH, or specified in the cmake settings dialog.
>
>> 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.
Agreed, that would be not so nice.
>
>>       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.
Well thats not entirely true for the unconfigured project case, the
NoTargetsPanel will pop up and the user can choose his builddirectory,
only if he presses "Configure" the builddir for the current buildconfig
is created and the project description files are generated.

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

Ok so what I would propose then:

Creating a new project:
    -> The user can select his project builddirectory right in the new
project wizard
         when selecting the Kits he wants to have added to his project
config,
         files are created only if he accepts the dialog

Opening a unconfigured project:
    -> The NoTargetsPanel will pop up, nothing is created until the user
presses the
         "Configure" button.

Changing buildconfiguration:
    -> Show the current settings in labels and have a "Change" button
that will pop up
         a dialog, the user can change all settings there and has to hit
a button saying something
         like "Accept & Run cmake".
>
> 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.
Thanks for your comments,

Benjamin
>
> Best Regards,
> Tobias
>