[Development] Android binary size with Clang

[Thiago Macieira]

Hello

Yesterday during the PDXCPP Meet Up, I was asked if we had come up with a good 
solution to the increase in size of native binaries on Android when switching 
from GCC to Clang. I reported I had no idea there was even a problem.

So, what's the status here?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Jean-Michaël Celerier]

> I never seen anything QtCreator had trouble with.

really ?
paste this in a .cpp and indent it :

#define WHATEVER

struct foo
{
WHATEVER

public:
explicit foo();
};

struct bar
{
public:
explicit bar();
};




---
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Jun 20, 2018 at 3:08 PM, Allan Sandfeld Jensen 
wrote:

> On Mittwoch, 20. Juni 2018 14:09:20 CEST Ivan Donchevskii wrote:
> > One more thing about clang-format.
> >
> > It might be really nice if we use it as a default formatting tool in Qt
> > Creator. And I really want to experiment with it and see how clang-format
> > can replace the indenter that we currently use (which has a lot of bug
> > reports about broken formatting for example with modern C++).
> >
>
> I never seen anything QtCreator had trouble with. But on the subject,
> there is
> one standard indentation features QtCreator has that clang-format can't
> reproduce. When you line-break an expression, clang-format will indent it
> a
> fixed amount from the beginning of the next line, where QtCreator will try
> to
> find places to line up with from the line above, including indenting from
> the
> last paranthesis For instance:
>
> int a = foobar(x) + foo(looongfunctionname(
>  looongvariablename));
>
> vs
>
> int a = foobar(x) + foo(looongfunctionname(
> looongvariablename));
>
>
> This semantic indentation is not something clang-format can do at the
> moment.
> At least if someone knows how, I would love to know, I have search
> everywhere,
> including the clang-format code.
>
> It is not so bad in this case, but once you have multiple line-break like
> that
> in a long function call, clang-formated code is essentionally just
> unformatted.
>
> In any case if we want to enforce clang-format everywhere, perhaps we
> shouldn't have QtCreator do smarter and more readable indentation that we
> do
> not allow in our repository?
>
> 'Allan
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Philippe]

> When you line-break an expression, clang-format will indent it a 
>fixed amount from the beginning of the next line,
> where QtCreator will try to find places to line up with from the line above, 
> including indenting from the 
> last paranthesis For instance:

I don't use QtCreator, but clang-format does it as you describe for QtCreator.
And this works very nicely (...most of the time).
Now, I don't remember which one of the many settings is responsible for this.

Philippe


On Wed, 20 Jun 2018 15:08:29 +0200
Allan Sandfeld Jensen  wrote:

> On Mittwoch, 20. Juni 2018 14:09:20 CEST Ivan Donchevskii wrote:
> > One more thing about clang-format.
> > 
> > It might be really nice if we use it as a default formatting tool in Qt
> > Creator. And I really want to experiment with it and see how clang-format
> > can replace the indenter that we currently use (which has a lot of bug
> > reports about broken formatting for example with modern C++).
> > 
> 
> I never seen anything QtCreator had trouble with. But on the subject, there 
> is 
> one standard indentation features QtCreator has that clang-format can't 
> reproduce. When you line-break an expression, clang-format will indent it a 
> fixed amount from the beginning of the next line, where QtCreator will try to 
> find places to line up with from the line above, including indenting from the 
> last paranthesis For instance:
> 
> int a = foobar(x) + foo(looongfunctionname(
>looongvariablename));
> 
> vs
> 
> int a = foobar(x) + foo(looongfunctionname(
> looongvariablename));
> 
> 
> This semantic indentation is not something clang-format can do at the moment. 
> At least if someone knows how, I would love to know, I have search 
> everywhere, 
> including the clang-format code. 
> 
> It is not so bad in this case, but once you have multiple line-break like 
> that 
> in a long function call, clang-formated code is essentionally just 
> unformatted.
> 
> In any case if we want to enforce clang-format everywhere, perhaps we 
> shouldn't have QtCreator do smarter and more readable indentation that we do 
> not allow in our repository?
> 
> 'Allan
>   
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Eirik Aavitsland]

On 20. juni 2018 13:23, Morten Sørvig wrote:




On 19 Jun 2018, at 17:33, Allan Sandfeld Jensen  wrote:

Btw. Just for your information.

I have attached a few random examples of what we can look forward too after
running an auto-"beautifying" tool over our hand-formated Qt code. And these
changes are NOT something we can configure out ouf of in clang-format, it is
just cases where it can't do any 
better.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Thanks, this should really be the first thing we do: run a pre-project
so that we can have an informed discussion.

The point of machine formatting is perhaps not to make code beautiful, rather
it is to have automated formatting in order to offload work from the humans.


Looking at qConvertRgb16To32:

Manual formatting:
 return 0xff00
 | c) << 3) & 0xf8) | (((c) >> 2) & 0x7))
 | c) << 5) & 0xfc00) | (((c) >> 1) & 0x300))
 | c) << 8) & 0xf8) | (((c) << 3) & 0x7));

Clang-format:
 return 0xff00 | c) << 3) & 0xf8) | (((c) >> 2) & 0x7)) | c) << 5) & 
0xfc00) | (((c) >> 1) & 0x300))
| c) << 8) & 0xf8) | (((c) << 3) & 0x7));

The manually formatted version clearly has something going for it.



Yup, I also did some manual testing on existing Qt code, and I generally 
found that


- clang-format's intra-line changes were fine (correcting white space in 
expressions etc.)


- but whenever clang-format would add or remove linebreaks, which it 
would quite often do, the changes were typically detrimental to 
readability, and often significantly so (as in the example above).


In my view, the readability improvements of the former in no way 
outweighs the readability damage of the latter. So to me this tool (or 
its config) is not ready to be trusted with the power of doing automatic 
(not developer reviewed & approved) changes.


- Eirik Aa.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Allan Sandfeld Jensen]

On Mittwoch, 20. Juni 2018 14:09:20 CEST Ivan Donchevskii wrote:
> One more thing about clang-format.
> 
> It might be really nice if we use it as a default formatting tool in Qt
> Creator. And I really want to experiment with it and see how clang-format
> can replace the indenter that we currently use (which has a lot of bug
> reports about broken formatting for example with modern C++).
> 

I never seen anything QtCreator had trouble with. But on the subject, there is 
one standard indentation features QtCreator has that clang-format can't 
reproduce. When you line-break an expression, clang-format will indent it a 
fixed amount from the beginning of the next line, where QtCreator will try to 
find places to line up with from the line above, including indenting from the 
last paranthesis For instance:

int a = foobar(x) + foo(looongfunctionname(
 looongvariablename));

vs

int a = foobar(x) + foo(looongfunctionname(
looongvariablename));


This semantic indentation is not something clang-format can do at the moment. 
At least if someone knows how, I would love to know, I have search everywhere, 
including the clang-format code. 

It is not so bad in this case, but once you have multiple line-break like that 
in a long function call, clang-formated code is essentionally just 
unformatted.

In any case if we want to enforce clang-format everywhere, perhaps we 
shouldn't have QtCreator do smarter and more readable indentation that we do 
not allow in our repository?

'Allan



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Arnaud Clère]

Hi,
Thiago, did you decide on something regarding QCborValue in Qt5.12?

For structured traces, we have to deal with any user-defined data types so, we 
can do with QCborValue, QJsonValue or QFoo too. Now, the value of exposing the 
common backend of QJson and QCbor as a QFoo binary format is not clear to me, 
and the "lowest common denominator" approach is inherently limited.

In my latest QBind prototype, we can write any user-defined type in various 
formats, and we can even take a copy of the user-defined type to serialize it 
later. So, QFoo is not required as an intermediate storage and would probably 
be slower. The latest benchmark shows the QBind approach can be *very* 
efficient:

(usecs)  |QDebug|Json|Cbor|Writable|Writable>Cbor
MSVC 17
 This email is to start that discussion and answer these questions:
>   a) should we have this API?
>   b) if so, what would this API look like?
>   c) if not, should we unify at least JSON and CBOR?
>   c) either way, should remove QCborValue until we have it?
...
> This API would also be the replacement of the JSON and CBOR parsers, 
> for which we'd have a unified API, something like:
>   QFoo json = QJson::fromJson(jcontent);
>   QFoo cbor = QCbor::fromCbor(ccontent);
>   qDebug() << QCbor::toDiagnosticFormat(json);// yes, json

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Ivan Donchevskii]

One more thing about clang-format.

It might be really nice if we use it as a default formatting tool in Qt 
Creator. And I really want to experiment with it and see how clang-format can 
replace the indenter that we currently use (which has a lot of bug reports 
about broken formatting for example with modern C++).


BR,
Ivan



From: Development  
on behalf of Sérgio Martins via Development 
Sent: Wednesday, June 20, 2018 1:56 PM
To: Frederik Gladhorn
Cc: Development; development@qt-project.org
Subject: Re: [Development] clang-format

On 2018-06-18 10:04, Frederik Gladhorn wrote:
> Hi all,
>
> as part of the closing ceremony of this year's Qt Contributors' Summit
> we
> agreed to start using clang-format, to have fewer discussions around
> coding
> style and rather focus on the actual code.
>
> I have not yet thought about all angles, how to best implement this,
> here are
> some notes:
>
> We have a clang-format file in qtrepotools. You can use it today,
> simply make
> sure it's in any parent directory of the files you are editing. I'd
> actually
> propose simply moving this into the root directory of qt5.git.
> https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format
>
> If you want to clean one file:
> clang-format -i myfile.cpp/h
>
> To clean a commit (only modifies the working tree):
> git clang-format
>
>
> Getting clang-format seems easy enough:
> On macOS: brew install clang-format
> Linux: install clang-format
> Windows: it comes with normal clang
>
> Then there is the tooling/workflow perspective. Creator and other IDEs
> have
> support (you may need to enable the beautifier plugin in about
> plugins).
> I imagine we add this to the sanity bot ("git clang-format --diff -q"
> should
> return empty, otherwise post a message).
>
> Local hooks are basically the same, any ideas how to best set up the
> git hooks
> appreciated :)
>
> And then there is the big question when we run it once over the entire
> codebase.

I find clang-format a bit limited and always need to manually format
some things that clang-format doesn't allow to tune.

It's quite useful when integrated with gerrit so it can automatically -1
the most common mistakes, but I wouldn't run it on the entire codebase.

So YES to all you said, except the massive cleanup.




Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Sérgio Martins via Development]

On 2018-06-18 10:04, Frederik Gladhorn wrote:

Hi all,

as part of the closing ceremony of this year's Qt Contributors' Summit 
we
agreed to start using clang-format, to have fewer discussions around 
coding

style and rather focus on the actual code.

I have not yet thought about all angles, how to best implement this, 
here are

some notes:

We have a clang-format file in qtrepotools. You can use it today, 
simply make
sure it's in any parent directory of the files you are editing. I'd 
actually

propose simply moving this into the root directory of qt5.git.
https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format

If you want to clean one file:
clang-format -i myfile.cpp/h

To clean a commit (only modifies the working tree):
git clang-format


Getting clang-format seems easy enough:
On macOS: brew install clang-format
Linux: install clang-format
Windows: it comes with normal clang

Then there is the tooling/workflow perspective. Creator and other IDEs 
have
support (you may need to enable the beautifier plugin in about 
plugins).
I imagine we add this to the sanity bot ("git clang-format --diff -q" 
should

return empty, otherwise post a message).

Local hooks are basically the same, any ideas how to best set up the 
git hooks

appreciated :)

And then there is the big question when we run it once over the entire
codebase.


I find clang-format a bit limited and always need to manually format 
some things that clang-format doesn't allow to tune.


It's quite useful when integrated with gerrit so it can automatically -1 
the most common mistakes, but I wouldn't run it on the entire codebase.


So YES to all you said, except the massive cleanup.




Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Tor Arne Vestbø]

On 20 Jun 2018, at 12:13, Lars Knoll  wrote:
> 
> I can’t see how clang-format will make you jump through any sort of hoops. 
> Creator already has a hook for doing it on file saving time afaik, 
> git-clang-format will clean up your change from the command line.

Good point, I was imagining it used only to verify style, not to auto-format. 
Still, starting out with a few non-controversial rules would be a good thing.

Tor Arne 


> 
> Lars
> 
>> On 20 Jun 2018, at 11:52, Tor Arne Vestbø  wrote:
>> 
>> How about we also start with only one or two  obvious rules that everyone 
>> agrees on? I don’t want Qt development to turn into Python PEP8 type rigid 
>> rules that makes you jump through a million hoops. If the latter is the goal 
>> here then I’m against enforcing clang-format, and it should be implemented 
>> as a bot that just warns, similar to the current style bot.
>> 
>> - Tor Arne
>> 
>>> On 20 Jun 2018, at 11:21, André Pönitz  wrote:
>>> 
 On Wed, Jun 20, 2018 at 06:30:26AM +, Lars Knoll wrote:
 
 
> On 19 Jun 2018, at 18:19, Ville Voutilainen
>  wrote:
> 
> On 19 June 2018 at 19:13, Philippe  wrote:
>>> For the above reasons I'd lean towards not running it globally and
>>> just using it on new changes.
>> 
>> +1, based on my clang-format experience on a big application.
>> 
>> BTW, keep in mind that you can disable clang-format on code
>> sections with:
>> 
>> // clang-format off // clang-format on
> 
> When I last experienced a large-scale clang-format reformat, it
> really hurt development during the churn. We should somehow manage
> to do it during a time when there aren't many pending patches in the
> pipeline. I'm not concerned about git-blame; that has never been a
> problem after reformats. However, I do not care about indentation
> nor do I want to spend time on it either way, it has no actual
> effect on readability and maintainability of code, and consistency
> outside the file you're in has never mattered to me one bit.
> 
> IOW, I'm not opposed to reformats and auto-checking of clang-format
> (or even hooking it), but I do not see it as a thing with all that
> great return-of-investment.
 
 It helps in that you do not need to point those things out in code
 reviews, and that I (and others) won’t even create changes with wrong
 formatting that I’ll need to fix up later on. It’s part of a larger
 story, where I would like to get as much automatic checking of changes
 done before humans start reviewing.
>>> 
>>> It's also a cultural thing.
>>> 
>>> Quite a few people seem to take less offense from a "Your formatting is
>>> bad" when the comment comes from a bot than when it comes from a human. 
>>> 
 One idea could be to introduce this incrementally. Let’s first start
 off with enforcing it for new changes. Then we run it globally over
 the code base shortly before Qt 6.0 is being released. At that time
 merges shouldn’t be as much of a problem (as we’ll probably
 cherry-pick into Qt 5.15) and by then all new changes in Gerrit will
 be properly formatted (due to the earlier hook).
>>> 
>>> Incrementally sounds good to me.
>>> 
>>> Still I am a bit of a fence here. So far I've seen a couple of auto-
>>> formatting attempts biting back, so I thinl it would help to convince me
>>> to see the kind of changes that would happen first before deciding
>>> on the global change.
>>> 
>>> Andre'
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
> 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5.12 feature freeze is getting closer

[Jani Heikkinen]

Hi all,

Only two months to Qt 5.12 feature freeze, see 
https://wiki.qt.io/Qt_5.12_Release. And summer vacations will take big part of 
that remaining period...

So at this point we should already know if there will be some new submodule 
modules in Qt 5.12. We are doing packaging confs etc for 5.12 now so please 
inform qt.team.relea...@qt.io (I am starting my vacation today) immediately if 
there will be some new in. And of course get the new submodule in qt5 as soon 
as possible; those really needs to be in before we start soft branching mid 
August!

br,
Jani

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Lars Knoll]

I can’t see how clang-format will make you jump through any sort of hoops. 
Creator already has a hook for doing it on file saving time afaik, 
git-clang-format will clean up your change from the command line.

Lars

> On 20 Jun 2018, at 11:52, Tor Arne Vestbø  wrote:
> 
> How about we also start with only one or two  obvious rules that everyone 
> agrees on? I don’t want Qt development to turn into Python PEP8 type rigid 
> rules that makes you jump through a million hoops. If the latter is the goal 
> here then I’m against enforcing clang-format, and it should be implemented as 
> a bot that just warns, similar to the current style bot.
> 
> - Tor Arne
> 
>> On 20 Jun 2018, at 11:21, André Pönitz  wrote:
>> 
>>> On Wed, Jun 20, 2018 at 06:30:26AM +, Lars Knoll wrote:
>>> 
>>> 
 On 19 Jun 2018, at 18:19, Ville Voutilainen
  wrote:
 
 On 19 June 2018 at 19:13, Philippe  wrote:
>> For the above reasons I'd lean towards not running it globally and
>> just using it on new changes.
> 
> +1, based on my clang-format experience on a big application.
> 
> BTW, keep in mind that you can disable clang-format on code
> sections with:
> 
> // clang-format off // clang-format on
 
 When I last experienced a large-scale clang-format reformat, it
 really hurt development during the churn. We should somehow manage
 to do it during a time when there aren't many pending patches in the
 pipeline. I'm not concerned about git-blame; that has never been a
 problem after reformats. However, I do not care about indentation
 nor do I want to spend time on it either way, it has no actual
 effect on readability and maintainability of code, and consistency
 outside the file you're in has never mattered to me one bit.
 
 IOW, I'm not opposed to reformats and auto-checking of clang-format
 (or even hooking it), but I do not see it as a thing with all that
 great return-of-investment.
>>> 
>>> It helps in that you do not need to point those things out in code
>>> reviews, and that I (and others) won’t even create changes with wrong
>>> formatting that I’ll need to fix up later on. It’s part of a larger
>>> story, where I would like to get as much automatic checking of changes
>>> done before humans start reviewing.
>> 
>> It's also a cultural thing.
>> 
>> Quite a few people seem to take less offense from a "Your formatting is
>> bad" when the comment comes from a bot than when it comes from a human. 
>> 
>>> One idea could be to introduce this incrementally. Let’s first start
>>> off with enforcing it for new changes. Then we run it globally over
>>> the code base shortly before Qt 6.0 is being released. At that time
>>> merges shouldn’t be as much of a problem (as we’ll probably
>>> cherry-pick into Qt 5.15) and by then all new changes in Gerrit will
>>> be properly formatted (due to the earlier hook).
>> 
>> Incrementally sounds good to me.
>> 
>> Still I am a bit of a fence here. So far I've seen a couple of auto-
>> formatting attempts biting back, so I thinl it would help to convince me
>> to see the kind of changes that would happen first before deciding
>> on the global change.
>> 
>> Andre'
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Tor Arne Vestbø]

How about we also start with only one or two  obvious rules that everyone 
agrees on? I don’t want Qt development to turn into Python PEP8 type rigid 
rules that makes you jump through a million hoops. If the latter is the goal 
here then I’m against enforcing clang-format, and it should be implemented as a 
bot that just warns, similar to the current style bot.

- Tor Arne

> On 20 Jun 2018, at 11:21, André Pönitz  wrote:
> 
>> On Wed, Jun 20, 2018 at 06:30:26AM +, Lars Knoll wrote:
>> 
>> 
>>> On 19 Jun 2018, at 18:19, Ville Voutilainen
>>>  wrote:
>>> 
>>> On 19 June 2018 at 19:13, Philippe  wrote:
> For the above reasons I'd lean towards not running it globally and
> just using it on new changes.
 
 +1, based on my clang-format experience on a big application.
 
 BTW, keep in mind that you can disable clang-format on code
 sections with:
 
 // clang-format off // clang-format on
>>> 
>>> When I last experienced a large-scale clang-format reformat, it
>>> really hurt development during the churn. We should somehow manage
>>> to do it during a time when there aren't many pending patches in the
>>> pipeline. I'm not concerned about git-blame; that has never been a
>>> problem after reformats. However, I do not care about indentation
>>> nor do I want to spend time on it either way, it has no actual
>>> effect on readability and maintainability of code, and consistency
>>> outside the file you're in has never mattered to me one bit.
>>> 
>>> IOW, I'm not opposed to reformats and auto-checking of clang-format
>>> (or even hooking it), but I do not see it as a thing with all that
>>> great return-of-investment.
>> 
>> It helps in that you do not need to point those things out in code
>> reviews, and that I (and others) won’t even create changes with wrong
>> formatting that I’ll need to fix up later on. It’s part of a larger
>> story, where I would like to get as much automatic checking of changes
>> done before humans start reviewing.
> 
> It's also a cultural thing.
> 
> Quite a few people seem to take less offense from a "Your formatting is
> bad" when the comment comes from a bot than when it comes from a human. 
> 
>> One idea could be to introduce this incrementally. Let’s first start
>> off with enforcing it for new changes. Then we run it globally over
>> the code base shortly before Qt 6.0 is being released. At that time
>> merges shouldn’t be as much of a problem (as we’ll probably
>> cherry-pick into Qt 5.15) and by then all new changes in Gerrit will
>> be properly formatted (due to the earlier hook).
> 
> Incrementally sounds good to me.
> 
> Still I am a bit of a fence here. So far I've seen a couple of auto-
> formatting attempts biting back, so I thinl it would help to convince me
> to see the kind of changes that would happen first before deciding
> on the global change.
> 
> Andre'
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[André Pönitz]

On Wed, Jun 20, 2018 at 06:30:26AM +, Lars Knoll wrote:
> 
> 
> > On 19 Jun 2018, at 18:19, Ville Voutilainen
> >  wrote:
> > 
> > On 19 June 2018 at 19:13, Philippe  wrote:
> >>> For the above reasons I'd lean towards not running it globally and
> >>> just using it on new changes.
> >> 
> >> +1, based on my clang-format experience on a big application.
> >> 
> >> BTW, keep in mind that you can disable clang-format on code
> >> sections with:
> >> 
> >> // clang-format off // clang-format on
> > 
> > When I last experienced a large-scale clang-format reformat, it
> > really hurt development during the churn. We should somehow manage
> > to do it during a time when there aren't many pending patches in the
> > pipeline. I'm not concerned about git-blame; that has never been a
> > problem after reformats. However, I do not care about indentation
> > nor do I want to spend time on it either way, it has no actual
> > effect on readability and maintainability of code, and consistency
> > outside the file you're in has never mattered to me one bit.
> > 
> > IOW, I'm not opposed to reformats and auto-checking of clang-format
> > (or even hooking it), but I do not see it as a thing with all that
> > great return-of-investment.
> 
> It helps in that you do not need to point those things out in code
> reviews, and that I (and others) won’t even create changes with wrong
> formatting that I’ll need to fix up later on. It’s part of a larger
> story, where I would like to get as much automatic checking of changes
> done before humans start reviewing.

It's also a cultural thing.

Quite a few people seem to take less offense from a "Your formatting is
bad" when the comment comes from a bot than when it comes from a human. 

> One idea could be to introduce this incrementally. Let’s first start
> off with enforcing it for new changes. Then we run it globally over
> the code base shortly before Qt 6.0 is being released. At that time
> merges shouldn’t be as much of a problem (as we’ll probably
> cherry-pick into Qt 5.15) and by then all new changes in Gerrit will
> be properly formatted (due to the earlier hook).

Incrementally sounds good to me.

Still I am a bit of a fence here. So far I've seen a couple of auto-
formatting attempts biting back, so I thinl it would help to convince me
to see the kind of changes that would happen first before deciding
on the global change.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Monitoring of upstream vulnerabilities

[Eike Ziller]

> On 19. Jun 2018, at 23:15, Jason H  wrote:
> 
> 
> 
>> Sent: Tuesday, June 19, 2018 at 4:50 PM
>> From: "Thiago Macieira" 
>> To: development@qt-project.org
>> Subject: Re: [Development] Monitoring of upstream vulnerabilities
>> 
>> On Tuesday, 19 June 2018 13:15:18 PDT Jason H wrote:
 Currently, we use https://github.com/clearlinux/cve-check-tool. This is
 going to be replaced with CVEMAN -
 https://github.intel.com/kcwells/cveman. Both tools consume the feed from
 the National Vulnerability Database from the US NIST -
 https://nvd.nist.gov/.
>>> 
>>> Is that intel server publicly accessible?
>> 
>> The dashboard the tool produces isn't, but I also don't see why you'd want 
>> that. It's not applicable to Qt. The only people who would want access to it 
>> are the people who are working on the distribution and will apply the 
>> patches.
> 
> !?
> 
> The first link is a publicly accessible project. I thought you were referring 
> to a replacement project. I wanted to see what CVEMAN was, why it was better, 
> etc., (having never hard of it before) and see if it was something I might be 
> interested in. But if it's not publicly accessible I wonder how open Qt is if 
> we can't use all the tools Qt does.  It could be valid that I don't need to 
> worry, but how does the bind Qt to a private tool?
> 
> I don't want to make a mountain out of a mole hill, but with all the 
> transparency in Qt, I just expected it to be accessible is all. 

These tools are currently not used for Qt.
Thiago is talking about "what we use in Clear Linux”, where “we” has nothing to 
do with the Qt Project.

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Merge and Integration status report

[Liang Qi]

Integrations

* qt5 dev integration failed from June 18
* * Issue: [QTBUG-68848][1] tst_QQmlDebugJS fails too often in CI, perhaps a 
duplicate of [QTBUG-68741][2], the issue is there about two weeks, more talks 
in [previous report][4]

* qt5 5.11 integration failed from June 9
* * Issue: [QTBUG-68773][3] qtwayland build failed - can't find some headers
* * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, 
Oswald please help to review it. Suggest to revert to get 5.11 integrated again.

Merges

* qtbase 5.11->dev, the merge is blocked because [QTBUG-68773][3] is not fixed 
yet.

-- Liang

[1]: https://bugreports.qt.io/browse/QTBUG-68666
[2]: https://bugreports.qt.io/browse/QTBUG-68741
[3]: https://bugreports.qt.io/browse/QTBUG-68773
[4]: http://lists.qt-project.org/pipermail/development/2018-June/032893.html

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Kari Oikarinen]

On 20.06.2018 09:30, Lars Knoll wrote:
>
>
>> On 19 Jun 2018, at 18:19, Ville Voutilainen 
 wrote:

>>
>> On 19 June 2018 at 19:13, Philippe  wrote:
 For the above reasons I'd lean towards not running it globally and 
just using it

 on new changes.
>>>
>>> +1, based on my clang-format experience on a big application.
>>>
>>> BTW, keep in mind that you can disable clang-format on code 
sections with:

>>>
>>> // clang-format off
>>> // clang-format on
>>
>> When I last experienced a large-scale clang-format reformat, it really
>> hurt development
>> during the churn. We should somehow manage to do it during a time when
>> there aren't
>> many pending patches in the pipeline. I'm not concerned about
>> git-blame; that has never
>> been a problem after reformats. However, I do not care about
>> indentation nor do I want
>> to spend time on it either way, it has no actual effect on readability
>> and maintainability
>> of code, and consistency outside the file you're in has never mattered
>> to me one bit.
>>
>> IOW, I'm not opposed to reformats and auto-checking of clang-format
>> (or even hooking it),
>> but I do not see it as a thing with all that great return-of-investment.
>
> It helps in that you do not need to point those things out in code 
reviews, and that I (and others) won’t even create changes with wrong 
formatting that I’ll need to fix up later on. It’s part of a larger 
story, where I would like to get as much automatic checking of changes 
done before humans start reviewing.

>
> One idea could be to introduce this incrementally. Let’s first start 
off with enforcing it for new changes. Then we run it globally over the 
code base shortly before Qt 6.0 is being released. At that time merges 
shouldn’t be as much of a problem (as we’ll probably cherry-pick into Qt 
5.15) and by then all new changes in Gerrit will be properly formatted 
(due to the earlier hook).

>

I think this is a good approach. It includes a period of time between 
taking the
formatting options into use and applying them globally. There's a good 
chance
that the used clang-format settings may change due to discussion as more 
people

and code are exposed to it. It would be a shame to have to globally reformat
*again* after a short period of time.

(I'm still not sold on the benefit of running the reformatting on 
existing code
outweighs the cost, but the suggested time would probably give the best 
balance

there.)

--
Kari
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Lars Knoll]

> On 19 Jun 2018, at 18:19, Ville Voutilainen  
> wrote:
> 
> On 19 June 2018 at 19:13, Philippe  wrote:
>>> For the above reasons I'd lean towards not running it globally and just 
>>> using it
>>> on new changes.
>> 
>> +1, based on my clang-format experience on a big application.
>> 
>> BTW, keep in mind that you can disable clang-format on code sections with:
>> 
>> // clang-format off
>> // clang-format on
> 
> When I last experienced a large-scale clang-format reformat, it really
> hurt development
> during the churn. We should somehow manage to do it during a time when
> there aren't
> many pending patches in the pipeline. I'm not concerned about
> git-blame; that has never
> been a problem after reformats. However, I do not care about
> indentation nor do I want
> to spend time on it either way, it has no actual effect on readability
> and maintainability
> of code, and consistency outside the file you're in has never mattered
> to me one bit.
> 
> IOW, I'm not opposed to reformats and auto-checking of clang-format
> (or even hooking it),
> but I do not see it as a thing with all that great return-of-investment.

It helps in that you do not need to point those things out in code reviews, and 
that I (and others) won’t even create changes with wrong formatting that I’ll 
need to fix up later on. It’s part of a larger story, where I would like to get 
as much automatic checking of changes done before humans start reviewing.

One idea could be to introduce this incrementally. Let’s first start off with 
enforcing it for new changes. Then we run it globally over the code base 
shortly before Qt 6.0 is being released. At that time merges shouldn’t be as 
much of a problem (as we’ll probably cherry-pick into Qt 5.15) and by then all 
new changes in Gerrit will be properly formatted (due to the earlier hook).

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development