[Qt-creator] Cmake plugin again
Zoltán Balogh
zoltan.balogh at canonical.com
Wed Jan 28 10:30:04 CET 2015
Hello Tobias,
Ubuntu does have an Ubuntu tab in the Tools->Options... dialog and that
is where the Ubuntu SDK's targets are managed. That is logical and and
clear.
But as as see there is no Kit or toolchain configuration under the
Android or Blackberry page either.
I as a developer would expect all toolchain and kit specific settings to
be found under the "Build & Run" page of the Options dialog. And as
André pointed out there's already a 'CMake' tab there. So I do not see a
reason not to fix the the cmake support of the QtCreator from the point
of UI consistency.
My main point here is that we want to contribute to the very generic and
universal cmake support of the QtCreator. The concept Benjamin proposed
is not Ubuntu speific, it would work on all platforms. I think it is a
solid and safe extension of the cmake plugin.
Not to be misunderstand here :) My aim is to get a green light from you
the upstream maintainers before we push the patches. It is clear that
Ubuntu SDK does need this extension. So we have two ways ahead of us. We
either fork the cmake plugin or we contribute our changes to the master.
No question that our objective is to contribute. Right now the Ubuntu
SDK offers a forked cmake and that is not cool. We are ready to spend
time on our proposal to meet the requirement of the upstream
maintainers. But it is not cool to run rounds and rounds with offering
patches after patches and being rejected. So that is why I kindly ask
for your suggestions so we can sync our concept to your expectations...
and after we know that our plans fit to yours we can safely start. Keep
in mind that the concept Benjamin presented is not a five liner patch...
So we can not just keep trying with new proposals and hope for the best.
The full implementation of this concept will be around 1-2k lines of
code and it will take weeks of work. So I assume we all agree that such
a work is better conducted in a different way than simple bugfixes or
short changes. So, yes I do hope we can continue the discussion and
shaping together the concept and finally get Daniel's approval on it.
Just to be fair and straight, we will not start working on a change
proposal without his ack on the idea. And keeping the forked cmake
plugin is something what nobody likes.
cheers,
Zoltan
On 01/28/2015 10:41 AM, Tobias Hunger wrote:
> 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