[Qt-creator] Cmake plugin again
Tobias Hunger
tobias.hunger at theqtcompany.com
Wed Jan 28 09:41:16 CET 2015
Hi Zoltán,
you may be inconsintent, but it is what all platforms have opted for so
far:-)
All of them wanted a place where they can manage their installations
(which kind of devices are supported, update the tools needed to build,
add new supported devices, etc.). I would be rather surprised if
cannonical did not want/need that. It seems like a natural place to set
up kits, too: All the information on which settings need to go together
into one kit is available at that point, so why not make use of that
information to set up kits for the user there? After all the typical
user cares about installing support for a new device. Very few want to
know that creator internally manages that new device support in the
form ob a bunch of settings called a kit.
I admit that this is somewhat ortogonal to supporting several cmake
setups. I also admit not having checked out the ubuntu SDK in a long
time, so maybe I am harboring misconceptions based on earlier versions
and how others did approach similiar problems.
--
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 6:05 , Zoltán Balogh
<zoltan.balogh at canonical.com> wrote:
> 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
>
> _______________________________________________
> 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