[Qt-creator] Cmake plugin again

[Tobias Hunger]

Hi Zoltan,

On Mi, Jan 28, 2015 at 10:30 , Zoltán Balogh 
<zoltan.balogh at canonical.com> wrote:
> 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.

Yeap. For android/iOS/blackberry these pages also create kits 
automatically as development targets/SDK 
/whatever-these-things-are-called-on-the-platform-of-choice come and go.

> But as as see there is no Kit or toolchain configuration  under the 
> Android or Blackberry page either.

The kits generated by those platforms are of course displayed in the 
kits page, along with the other kits.

They are just created/removed by the platform specific code.

> 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.

When you proceed to move cmake configuration into the kits, then the 
current page little sense and could be removed altogether.

Alternatively it can be replaced by a management page as proposed by 
Benjamin.

I have no strong oppinion either way on the topic, but am trying to 
find out whether having a management page is worth having in spite of 
the clutter each page introduces to the UI.

> 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.

I agree that this concept makes sense and can be generic. Your use-case 
is a bit different from e.g. the one described by Mathias, but that is 
to be expected. We just need try and cover all of these use-cases and 
we are fine:-)

> 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.

Not to be misunderstood here either:-) I am not challenging your 
use-case nor having cmake in the kit. All I am curious about is the 
reasoning for having the UI to configure the cmake found in the kit on 
a separate page. Such a page does introduce some overhead to manage the 
different cmake installations (have some manager to access the 
available configuration, write state to disk, extend sdktool so the 
installer can set this information, handle upgrades gracefully and 
more).

Of course this overhead can be necessary to e.g. enable caching of 
hard-to-get/expensive information and lots of other reasons. Even 
simple things like the UI to configure this piece of information being 
too complex to fit into the kit configuration UI. I am sure Benjamin 
had some reason to propose this page.

Discussions on how to arange the pages, whether they are still useful 
or not and how we can improve the work-flow for those pages happen 
constantly, so this is in no way specific to Benjamins proposal.

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