On Tuesday, 8 November 2022 12:59:39 PST Niclas Rosenvik wrote:
> /home/qt/work/qt/qtbase/build/target/include/QtCore/../../../../src/corelib/
> ipc/qtipccommon.h:125:21: warning: 'QNativeIpcKey::TypeAndFlags::type' is
> too small to hold all values of 'enum class QNativeIpcKey::Type'
This one is
On Tue, 08 Nov 2022 10:35:08 -0800
Thiago Macieira wrote:
> On Saturday, 5 November 2022 22:59:06 PST Thiago Macieira wrote:
> > Ok, now I need QNX help from build
> > https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1679395790
>
> ping, anyone?
>
> I've updated the configure summary
On Saturday, 5 November 2022 22:59:06 PST Thiago Macieira wrote:
> Ok, now I need QNX help from build
> https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1679395790
ping, anyone?
I've updated the configure summary to include whether the key was enabled and
it was indeed NOT enabled:
-
On Saturday, 5 November 2022 11:35:15 PDT Thiago Macieira wrote:
> TL;DR: Please propose a patch by end of week to fix the INTEGRITY error from
> https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1679359812
Ok, now I need QNX help from build
https://testresults.qt.io/coin/integration/qt/q
TL;DR: Please propose a patch by end of week to fix the INTEGRITY error from
https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1679359812
Longer:
I have a 34-patch series refactoring a lot of the IPC mechanisms in Qt, in
particular QSharedMemory and QSystemSemaphore. It starts here:
ht
Hi,
Documentation is the authorative source. It is maintained and checked for each
Qt release. We should make sure the platform notes are correct and complete.
Misleading information in wiki should be deleted or marked as deprecated.
Similar activity has been done to other pages, sometimes we m
Il 20/09/19 07:53, Tuukka Turunen ha scritto:
Or remove the wiki entry and make sure platform notes in documentation are in
shape?
No need for duplicated info on these basic items.
It's a bigger problem -- the *same* wiki is used for official
information (e.g. releasing info; coding guidelin
On Fri, 20 Sep 2019 at 10:10, Allan Sandfeld Jensen wrote:
> I am pretty sure we strongly depend on some of those features now.
> Realistically I don't think we support any compiler older than what the CI
> tests for which I believe is GCC 4.9.
Close enough, 4.8.
On Friday, 20 September 2019 00:07:38 CEST Thiago Macieira wrote:
> On Thursday, 19 September 2019 03:17:12 PDT Giuseppe D'Angelo via
> Development
> wrote:
> > On 18/09/2019 17:33, Thiago Macieira wrote:
> > >>> We've never required C++11 Standard Library. We've only required the
> > >>> core
> >
Or remove the wiki entry and make sure platform notes in documentation are in
shape?
No need for duplicated info on these basic items.
Yours,
Tuukka
On 19/09/2019, 23.52, "Development on behalf of Kai Pastor, DG0YT"
wrote:
Am 19.09.19 um 10:41 schrieb Mutz, Marc via Developm
On Thu, Sep 19, 2019 at 11:37:14PM +0200, Giuseppe D'Angelo wrote:
> Il 19/09/19 21:53, Kyle Edwards ha scritto:
> > As a generalization of this, perhaps Qt could introduce something like
> > a Q_CONSTEXPR macro, which does what we expect on platforms that
> > support it, and compiles to nothing on
On Thursday, 19 September 2019 03:17:12 PDT Giuseppe D'Angelo via Development
wrote:
> On 18/09/2019 17:33, Thiago Macieira wrote:
> >>> We've never required C++11 Standard Library. We've only required the
> >>> core
> >>> language and the integrity compiler does support it just fine.
> >>
> >> N
On Thursday, 19 September 2019 12:14:36 PDT Giuseppe D'Angelo via Development
wrote:
> On 19/09/2019 21:01, André Pönitz wrote:
> > "Is it worth" is exactly the question that should drive this kind of
> > discussion. And it can be answered_after_ evaluating, or even guessing
> > the "value" of th
On Thursday, 19 September 2019 01:41:49 PDT Mutz, Marc via Development wrote:
> > Seems like it. Like I said, we've never required the C++11 standard
> > library
> > and we need to be sure the feature we need is supported before we
> > commit to
> > it.
>
> https://www.qt.io/blog/2016/06/16/qt-5-7
Il 19/09/19 21:53, Kyle Edwards ha scritto:
As a generalization of this, perhaps Qt could introduce something like
a Q_CONSTEXPR macro, which does what we expect on platforms that
support it, and compiles to nothing on Integrity.
It's already in Qt, and used:
https://code.woboq.org/qt5/qtbase
Am 19.09.19 um 10:41 schrieb Mutz, Marc via Development:
1. List a maintainer for INTEGRITY in https://wiki.qt.io/Maintainers
2. That maintainer should either find the missing linker flag, or file
a bug with Integrity
3. If there's a work-around (providing those missing functions in Qt,
e.g.),
On Thu, 2019-09-19 at 21:50 +0200, André Pönitz wrote:
> Having constexpr or not on certain functions could depend on the
> actual
> compiler in some cases, providing the performance benefits for the
> compilers supporting it, and still keeping platforms with unsuitable
> compilers alive.
As a ge
On Thu, Sep 19, 2019 at 09:14:36PM +0200, Giuseppe D'Angelo via Development
wrote:
> On 19/09/2019 21:01, André Pönitz wrote:
> > "Is it worth" is exactly the question that should drive this kind of
> > discussion.
> > And it can be answered_after_ evaluating, or even guessing the "value" of
>
On 19/09/2019 21:01, André Pönitz wrote:
"Is it worth" is exactly the question that should drive this kind of discussion.
And it can be answered_after_ evaluating, or even guessing the "value" of the
available options.
It's not so easy: I, for once, don't have access to INTEGRITY to do any
a
On Thu, Sep 19, 2019 at 11:18:26AM +0200, Mutz, Marc via Development wrote:
> But it helps nothing with all the places where we use QWaitCondition in Qt
> implementation and would like to replace it with std::condition_variable +
> std::mutex, because, as I explained in an earlier mail, QWaitCondit
On Thu, 19 Sep 2019 at 16:40, Mutz, Marc wrote:
> > This problem is under fixing; the kernel we use in our CI build simply
> > doesn't support condition variables, and thus its run-time library
> > doesn't have
> > them either.
>
> That's interesting. Are you saying I just overlooked that QWaitCo
Hi Tuukka, Ville,
On 2019-09-19 15:02, Ville Voutilainen wrote:
On Thu, 19 Sep 2019 at 14:49, Tuukka Turunen
wrote:
A lot of the Qt functionality works perfectly well on INTEGRITY. Even
the advanced graphics such as Qt Quick, Qt 3D and Qt 3D Studio. I do
not see it reasonable to claim that it
On Thu, 19 Sep 2019 at 14:49, Tuukka Turunen wrote:
>
>
> Hi Marc,
>
> A lot of the Qt functionality works perfectly well on INTEGRITY. Even the
> advanced graphics such as Qt Quick, Qt 3D and Qt 3D Studio. I do not see it
> reasonable to claim that it is "so far behind all the other supported
On Thu, 19 Sep 2019 at 12:03, Mutz, Marc via Development
wrote:
> > 1. List a maintainer for INTEGRITY in https://wiki.qt.io/Maintainers
>
> That person seems to be Ville.
That impression is incorrect. I was merely asked to help resolve this
particular problem.
___
Hi Marc,
A lot of the Qt functionality works perfectly well on INTEGRITY. Even the
advanced graphics such as Qt Quick, Qt 3D and Qt 3D Studio. I do not see it
reasonable to claim that it is "so far behind all the other supported
platforms, as well as its own claim of conformance, that the ques
> On 19 Sep 2019, at 12:17, Giuseppe D'Angelo via Development
> wrote:
>
> On 18/09/2019 17:33, Thiago Macieira wrote:
We've never required C++11 Standard Library. We've only required the core
language and the integrity compiler does support it just fine.
>>> Not really, it also fails
On 18/09/2019 17:33, Thiago Macieira wrote:
We've never required C++11 Standard Library. We've only required the core
language and the integrity compiler does support it just fine.
Not really, it also fails on constexpr:
https://codereview.qt-project.org/c/qt/qtbase/+/264550
No, it has a bug i
On 2019-09-19 10:56, Lars Knoll wrote:
4. drop Integrity support (or update to a newer version) ASAP (for
Qt 5.15 if not 5.14).
This is a bit black and white. You’re proposing to drop all of
INTEGRITY because you’re not willing to work around things on that
platform for one patch that is in pr
ausmann
Sent: torstai 19. syyskuuta 2019 10.15
To: development@qt-project.org; Giuseppe D'Angelo
Subject: Re: [Development] INTEGRITY
Hi,
Unfortunately that will not work out of the box :-(. The tests are only
compiled when runinng tests. It is not feasible to run tests on Integrity
> On 19 Sep 2019, at 11:00, Mutz, Marc via Development
> wrote:
>
> From a comment by Ville on Gerrit, I take that:
>
> On 2019-09-19 10:41, Mutz, Marc via Development wrote:
>> So, I update my requests:
>> 1. List a maintainer for INTEGRITY in https://wiki.qt.io/Maintainers
>
> That person
From a comment by Ville on Gerrit, I take that:
On 2019-09-19 10:41, Mutz, Marc via Development wrote:
So, I update my requests:
1. List a maintainer for INTEGRITY in https://wiki.qt.io/Maintainers
That person seems to be Ville.
2. That maintainer should either find the missing linker flag,
On 19 Sep 2019, at 10:41, Mutz, Marc via Development
mailto:development@qt-project.org>> wrote:
On 2019-09-18 17:33, Thiago Macieira wrote:
On Wednesday, 18 September 2019 08:16:46 PDT Giuseppe D'Angelo via Development
wrote:
> We've never required C++11 Standard Library. We've only required the
On 2019-09-18 17:33, Thiago Macieira wrote:
On Wednesday, 18 September 2019 08:16:46 PDT Giuseppe D'Angelo via
Development
wrote:
> We've never required C++11 Standard Library. We've only required the core
> language and the integrity compiler does support it just fine.
Not really, it also fai
Il 19/09/19 09:14, Simon Hausmann ha scritto:
Unfortunately that will not work out of the box :-(. The tests are only
compiled when runinng tests. It is not feasible to run tests on
Integrity for every qtbase integration.
Uhm, ok. I somehow assumed that "-nomake tests" was being passed to
con
On Thu, Sep 19, 2019 at 07:14:30AM +, Simon Hausmann wrote:
Unfortunately that will not work out of the box :-(. The tests are only
compiled when runinng tests. It is not feasible to run tests on
Integrity for every qtbase integration.
really? the task about that was marked as done just a
project.org
Subject: Re: [Development] INTEGRITY
Il 18/09/19 13:52, Simon Hausmann ha scritto:
> Since the problem seems urgent to you, do you have any suggestion what
> kind of target built binary you'd add to qtbase's build coverage that
> includes linkage?
Random su
On Wednesday, 18 September 2019 08:16:46 PDT Giuseppe D'Angelo via Development
wrote:
> > We've never required C++11 Standard Library. We've only required the core
> > language and the integrity compiler does support it just fine.
>
> Not really, it also fails on constexpr:
>
> https://coderevie
Il 18/09/19 17:07, Thiago Macieira ha scritto:
On Wednesday, 18 September 2019 03:29:39 PDT Mutz, Marc via Development wrote:
Qt 5.14 is the eighth release of Qt to require C++11. How did we get
into a situation where there's one platform that doesn't even support
basic C++11? Why wasn't it drop
On Wednesday, 18 September 2019 03:29:39 PDT Mutz, Marc via Development wrote:
> Qt 5.14 is the eighth release of Qt to require C++11. How did we get
> into a situation where there's one platform that doesn't even support
> basic C++11? Why wasn't it dropped when MSVC 2013 was?
We've never require
Il 18/09/19 13:52, Simon Hausmann ha scritto:
Since the problem seems urgent to you, do you have any suggestion what
kind of target built binary you'd add to qtbase's build coverage that
includes linkage?
Random suggestion: build (if not even *run*) the autotests?
My 2 c,
--
Giuseppe D'Angelo
Hi,
I'm afraid that I don't have answers to all of your questions (due to
lack of knowledge), but for some I may be able to provide insight.
Am 18.09.19 um 12:29 schrieb Mutz, Marc via Development:
> Hi,
>
> Can someone expand on the plan forward for the supported INTEGRITY
> toolchains?
>
> La
Quoting https://www.ghs.com/products/compiler.html:
C++11 and C++14 support
Green Hills Compilers support ISO/IEC 14882:2011 (C++11) and
ISO/IEC 14882:2014 (C++14) which offers a number of new
language features and standard libraries. These includes
standardized threading support for mutexes, a
Hi,
Can someone expand on the plan forward for the supported INTEGRITY
toolchains?
Lars is talking about using C++17 for Qt 6, yet the INTEGRITY version in
the CI for Qt 5.14 doesn't even support C++_11_. It's a constant pain
for anything constexpr-related, and now it turns out that while it
On Wed, Mar 02, 2016 at 09:00:55AM -0800, Thiago Macieira wrote:
> On quarta-feira, 2 de março de 2016 08:24:50 PST Rolland Dudemaine wrote:
> > I understand that 5.7 has now reached feature freeze, but I would like
> > to ask for an exception for patches that have been pushed a few months
> > ago
On 02.03.2016 18:00, Thiago Macieira wrote:
On quarta-feira, 2 de março de 2016 08:24:50 PST Rolland Dudemaine wrote:
Hi,
I understand that 5.7 has now reached feature freeze, but I would like
to ask for an exception for patches that have been pushed a few months
ago already but never got merge
On quarta-feira, 2 de março de 2016 08:24:50 PST Rolland Dudemaine wrote:
> Hi,
>
> I understand that 5.7 has now reached feature freeze, but I would like
> to ask for an exception for patches that have been pushed a few months
> ago already but never got merged (partially because of the CI woes).
--Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=theqtcompany@qt-project.org] On Behalf Of
> Rolland Dudemaine
> Sent: Wednesday, 2 March 2016 9:07
> To: Liang Qi
> Cc: development@qt-project.org
> Subject: Re: [Development] INT
t: Re: [Development] INTEGRITY changes for 5.7
Do you plan to have them in 5.7 release? Current dev branch means 5.8...
On 2 March 2016 at 08:24, Rolland Dudemaine
mailto:roll...@ghs.com>> wrote:
Hi,
I understand that 5.7 has now reached feature freeze, but I would like
to ask for an ex
Do you plan to have them in 5.7 release? Current dev branch means 5.8...
On 2 March 2016 at 08:24, Rolland Dudemaine wrote:
> Hi,
>
> I understand that 5.7 has now reached feature freeze, but I would like
> to ask for an exception for patches that have been pushed a few months
> ago already but
Hi,
I understand that 5.7 has now reached feature freeze, but I would like
to ask for an exception for patches that have been pushed a few months
ago already but never got merged (partially because of the CI woes).
This would cover all the patches with a positive code review status at
https://cod
50 matches
Mail list logo
