On Friday, 6 December 2019 13:03:31 PST René J.V. Bertin wrote:
> >So you're building QtWebEngine with GCC 8 while Qt was built with clang
> >mkspec ?
>
> It was a test, but IMHO it should be possible (as long as you're not also
> mixing libstdc++ and libc++).
Building different parts of Qt with
On Friday December 06 2019 18:36:52 Sérgio Martins wrote:
>So you're building QtWebEngine with GCC 8 while Qt was built with clang
>mkspec ?
It was a test, but IMHO it should be possible (as long as you're not also
mixing libstdc++ and libc++).
>Anyway, FWIW, I've built QtWebEngine with clang
On 2019-12-06 16:42, René J.V. Bertin wrote:
Hi,
(...)
This was after I got this error from an attempt to build QtWebEngine
5.12.6 with /usr/bin/c++ which points to GCC 8:
So you're building QtWebEngine with GCC 8 while Qt was built with clang
mkspec ?
```
Using gcc version 4.2, but at le
Volker Hilsheimer wrote:
>> Sounds nice, but the reality is that this has not been the
>> case. Forward-merging hasn't worked without a fair bit of
>> hand-holding; one big difference is that forward-merging is a
>> centralized process, so the hand-holidng had to be done by the merge
>> master who
> -Original Message-
> From: Milian Wolff
>
> On Mittwoch, 4. Dezember 2019 12:23:00 CET Lukast dev wrote:
> > is there some Qt solution for producing traces used for performance
> > analysis?
> >
> > There is on-going work for LTTNG and ETW in Qt I noticed, e.g. here
> > https://coderevie
Hi,
Thiago suggested below that I submit my API proposal for serialization
outside of QtCore to see whether it makes sense.
I understood it would require a new repo as a playground for a kind of
"preview" module.
Should I go on creating a QTQAINFRA issue for that?
See details below.
Thanks,
Arnau
On Friday, 6 December 2019 08:42:38 PST René J.V. Bertin wrote:
> QT_GCC_MAJOR_VERSION = 3
> QT_GCC_MINOR_VERSION = 2
> QT_GCC_PATCH_VERSION = 1
This is wrong. Clang reports GCC 4.2.1, not 3.2.1.
> QT_CLANG_MAJOR_VERSION = 5
> QT_CLANG_MINOR_VERSION = 0
> QT_CLANG_PATCH_VERSION = 2
This Clang is
> Sounds nice, but the reality is that this has not been the case.
> Forward-merging hasn't worked without a fair bit of hand-holding; one big
> difference is that forward-merging is a centralized process, so the
> hand-holidng had to be done by the merge master who has nothing to do with
> either
Hi,
I just noticed this on Linux, after building Qt 5.12.6 with clang 5.0.2 :
```
> cat /opt/local/libexec/qt512/mkspecs/qconfig.pri
QT_ARCH = x86_64
QT_BUILDABI = x86_64-little_endian-lp64
QT.global.enabled_features = shared rpath c++11 c++14 c++1z c99 c11 thread
future concurrent pkg-con
> On 6 Dec 2019, at 14:45, Filippo Cucchetto wrote:
>> Il giorno ven 6 dic 2019 alle ore 11:18 Volker Hilsheimer
>> ha scritto:
>> > * Fresh commits are normally only allowed on dev, with an exception for
>> > changes files and last-minute hot-fixes on release branches.
>> > * Every commit has
I'm just a follower of this thread and i don't pretend to having understood
everything but i dont' really get how having backward commits from dev to
previous release branch could be handled from a dev point of view.
How can you automatically backport a simple fix that is using a particular
C++ sta
> On 27 Nov 2019, at 11:57, Edward Welbourne wrote:
>
> Volker Hilsheimer (26 November 2019 15:42) wrote:
> [snip]
>> If I understood and remember the discussion, then the proposed flow
>> would be:
>>
>> * we make changes to e.g changes-5.12.7 in the 5.12 branch
>> * once 5.12.7 is released, re
> On 5 Dec 2019, at 20:05, André Pönitz wrote:
>
> On Thu, Dec 05, 2019 at 06:12:53PM +0100, Giuseppe D'Angelo via Development
> wrote:
>> Il 04/12/19 12:56, Volker Hilsheimer ha scritto:
>>> IIRC, then I added that in the early Qt 2 days, anticipating that with
>>> Qt/Embedded we might see our
13 matches
Mail list logo
