[Qt-creator] Cmake plugin again

[Tobias Hunger]

Hi Benjamin,

I see no reason not to do that in the KitConfigWidget. I do not expect 
this to change often enough to warrant not simply re-running the 
detection step whenever a executable is set that looks like a cmake. 
You need to validate the kit configuration anyway, independently of 
whether or not you have a separate cmake page or not.

What information would go on the cmake-management page? Just a list 
view of known cmakes and a lineedit to show the path of the currently 
selected one? That seems a bit too little information to warrant a 
separate page to me. Qt versions do have a lot more state, so do the 
toolchains. I also expect users to have lot of Qt versions and 
toolchains, and to switch between them on a regular basis. I do not see 
any of this for cmake. Of course that might be only because I have not 
used cmake in earnest in a long time. I definitely see that we should 
support Mathias' use-case, but having a cmake binary in a kit should 
cover that nicely.

Of course you have a somewhat different use-case in ubuntu with the 
one-cmake-per-chroot approach. But even there the chroot is the thing 
you want to switch and not the cmake binary: That is just a means to 
the end. I would personally expect some ubuntu-specific page that helps 
users register/deregister and manage their target environments. That 
should of course manage the kits associated with those target 
environments. Each kit can of course include the appropriate cmake 
binary if that is necessary.

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

Email: tobias.hunger at theqtcompany.com | Phone: +49 30 63 92 3255 
www.qt.io | Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
@Qtproject | Facebook: www.facebook.com/qt

On Di, Jan 27, 2015 at 4:33 , Benjamin Zeller 
<benjamin.zeller at canonical.com> wrote:
> Am 27.01.2015 um 16:26 schrieb Tobias Hunger:
>>  Hi Mathias,
>> 
>>  ok, I see that use-case, but I do not see why cmake needs an options
>>  page of its own.
>> 
>>  I still think Just adding the path to the right cmake binary to the
>>  kit would suffice.
> In fact, I thought about this. But QtCreator needs to run detection
> code for every cmake instance. Like supported generators and so
> on.
> If the Kits just have a path instead of a central registry like the
> toolchains
> when and how should this code be executed?
>> 
>>  Best Regards,
>>  Tobias
>> 
>>  On Tue, Jan 27, 2015 at 4:16 PM, Mathias Hasselmann
>>  <mathias at taschenorakel.de> wrote:
>>> 
>>>  Am 27.01.2015 um 15:27 schrieb Daniel Teske:
>>>>>  its been a while since we last merged the upstream CMake plugin
>>>>>  into our own Ubuntu-SDK codebase. As a result our current version
>>>>>  is behind the most recent QtC release.
>>>>>  Since the last merge there were a lot of things changed in the 
>>>>> plugin
>>>>>  that makes it almost impossible to merge it again, so we decided 
>>>>> to
>>>>>  start from scratch and since we have learned from the last time 
>>>>> we
>>>>>  want to first propose the refactoring steps we are going to work 
>>>>> on.
>>>>> 
>>>>>  We decided to drop the idea of removing the "Run cmake" dialog 
>>>>> but
>>>>>  still need a possibility to have a cmake per Kit.
>>>>> 
>>>>>  So here are the steps, each one would be a self contained patch:
>>>>> 
>>>>>  Patch 1:
>>>>>  -> Add a view to register multiple cmake instances to the system 
>>>>> (in
>>>>>        tools->options->Build&Run->cmake)
>>>>>            * The user can select a default cmake tool that will 
>>>>> be used for
>>>>>  every build
>>>>>            * do not add it to the Kit yet to keep the patch small
>>>>>            * use a view like in the QtVersions settings page 
>>>>> (treeview)
>>>>>            * provide a central registry for all the cmake 
>>>>> instances
>>>>>  (CMakeToolManager)
>>>>> 
>>>>>  Patch 2:
>>>>>  -> Make the cmake instances known to the Kits 
>>>>> (CMakeKitInformation)
>>>>>            * The run cmake dialog will pick up the cmake from the 
>>>>> kit
>>>>> 
>>>>>  Patch 1 is rather big, but I do not see a way to break it down 
>>>>> even
>>>>>  more, but
>>>>>  I'm open for suggestions :).
>>>>> 
>>>>>  Daniel, can you please tell me if this proposal as the base of 
>>>>> our
>>>>>  implementation
>>>>>  is acceptable for you?
>>>>  So I have only limited understanding of your setup and needs, 
>>>> thus I can only
>>>>  comment on this in isolation. There have been some people wanting 
>>>> to have
>>>>  multiple different cmake executables, but that's a fringe use 
>>>> case as far as
>>>>  I'm concerned.
>>>  That's not too fringe in my opinion: I regularly encounter the 
>>> situation
>>>  that I'd need cmake 3.0 or even master for experimental or new 
>>> project,
>>>  while having to stay with 2.8.12 (or even older) for customer 
>>> projects.
>>>  Sucks to leave QtCreator in those scenarios. For CMake there really
>>>  should be different versions supported. Just as for compilers and 
>>> for Qt
>>>  versions.
>>> 
>>>  Ciao,
>>>  Mathias
>>>  _______________________________________________
>>>  Qt-creator mailing list
>>>  Qt-creator at qt-project.org
>>>  http://lists.qt-project.org/mailman/listinfo/qt-creator
>>  _______________________________________________
>>  Qt-creator mailing list
>>  Qt-creator at qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/qt-creator
> 
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator