[Qt-creator] Refactoring the CMake plugin

Benjamin Zeller benjamin.zeller at canonical.com
Wed Jun 18 16:02:36 CEST 2014


Am 18.06.2014 15:31, schrieb Hunger Tobias:
> Hi Benjamin,
>
> On 18.06.2014 15:12, Benjamin Zeller wrote:
> <snip out part about CMakeManager and CMakeTool>
>
>>> 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.
> We need to have a way for the kit to extend the environment anyway, so 
> the environment variables should be covered by that functionality (to be 
> written;-).
>
> CMake arguments, etc. can all be added in a script. I do not see why 
> that has to go into Qt Creator, especially considering that this is 
> static configuration that the user will rarely want to change.
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?
>> 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.
> Yes, we should be flexible and allow users to do whatever they want, but 
> we do not need to provide an UI for everything anybody may conceivably 
> come up with.
>
> This is one of those things IMHO.
>
>> Also for example if you want to configure a special toolchain file, or
>> just for
>> identifying a special type of cmake in the sourcecode.
> 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.
>> 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...
> For the phones and other stuff you have to have devices to talk to those 
> anyway, so why not use the type of device as a identification? You will 
> need to do different deployment steps based on which device you have anyway.
Good point, I can use the device type id.
> <snip part about mapping CMakeTools to Kits>
>
>>> 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.
> 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 :).
> 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.

Best Regards,

Benjamin
> I have nothing further to contribute to the discussion about when to run 
> cmake, so I will just cut out that part.
> Best Regards,
> Tobias
>




More information about the Qt-creator mailing list