[Qt-creator] Refactoring the CMake plugin

[Hunger Tobias]

On 18.06.2014 16:02, Benjamin Zeller wrote:
<snip>

> Ok, sounds good to me, so how would you want to have the Kit to extend the
> environment?
> Like having a KitInformation::addToEnvironment when the buildsteps are
> executed?

Add a EnvironmentKitInformation that can be configured to change the 
environment and then use the existing addToEnvironment, yes.

<snip>

>> There are different kinds of cmake? That is new to me. I always grabbed
>> the one from kitware.
> Yeah well, in our case we have build chroots that contain their own cmake
> instance and I need to invoke them inside the chroot. Thats probably
> why I needed all these things in the first place.

So you have host-binaries in a chroot for the target? Why would you do that?

You could have a sysroot set and then compare that to the cmake path. If 
sysroot is a prefix to cmake path, then you need to chroot... or do 
something similar.

>>> For example the
>>> ubuntu sdk plugin identifies Ubuntu SDK kits by checking if the cmake
>>> tool is of a special type.
>> Why would you do that?
>>
>> Desktop ubuntu (is that even supported?) is a pretty normal desktop
>> target, so why have a special type for that in the first place? And why
>> bind that type to cmake? Why do you want to limit users to the cmake
>> build system?
> The binding to that type of cmake just would happen for the special
> case I mentioned above, cross compiling in the chroots...

... which is actually pretty easily done with a script;-)

>> Why do you need a default cmake? Just use the one from PATH if the user
>> has none explicitly set (and there is one in PATH).

> Default cmake as in, the one to use when none is set in the Kit. And yes
> that would be the one from the PATH :).

No, if there is no cmake set in the kit, then this kit is not applicable 
for cmake-based projects. So you can just skip those kits when asking 
which ones the user wants to see his cmake project built with.

>> In the cmake wizard you then need to have the user select a kit (one
>> with a configured cmake) and off she goes.
> Ah yeah we can make the cmake wizard  just show Kits that actually have
> a cmake set,
> that would work also but requires more configuration from a user who
> just wants to
> use cmake without any fancy things. I would like to have the
> KitInformation fall back
> to the cmake in PATH.

Feel free to do that. That is why the KitInformation has methods for 
default values, for the initial setup and to fix it again in case 
something breaks:-)

Please make sure to only add cmake to kits where that actually makes 
sense. E.g. if there is no way to deploy cmake built binaries to the 
device in question, then just leave out the cmake for those kits. A user 
is still free to configure those kits manually if he knows what he does.

Best Regards,
Tobias