[Qt-creator] Cmake plugin again

Zoltán Balogh zoltan.balogh at canonical.com
Tue Jan 27 18:05:50 CET 2015 

Somehow I find inconsistent to handle Kits in two different places based 
on what OS the developer is targeting.

I always liked in QtC that it has a single place where Kits are managed. 
I expect to organize all the tools and rootfs's under it and not vica versa.

Not to mention that our objective here is to upstream the cmake specific 
development we have done and making an Ubuntu specific page will not 
support our case, will it :)


cheers,

Zoltan

On 27/01/15 18:32, Tobias Hunger wrote:
> 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
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator

More information about the Qt-creator mailing list