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.maci
> 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, 2
> 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-f
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
change
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
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 c
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
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
> 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 confi
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 use
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.
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 w
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 impleme
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.
> >>
> >> +
> 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:
Curr
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-6
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 e
17 matches
Mail list logo
