Re: [Development] INTEGRITY help needed: IPC & QT_CONFIG weirdness

[Thiago Macieira]

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 expected and intentional. Type is an enum class with quint16 
underlying type, so it cannot store all 65536 values on 15 bits.

> Is this the error that causes QNativeIpcKey::Type::SystemV to be the
> value you mentioned?

No, it isn't. The values in question are all less than 9 bits in size.

The issue appears to be that QT_POSIX_IPC isn't #define'd in qtcore-config.h. 
This is the configure.cmake content:

qt_feature("ipc_posix"
LABEL "Defaulting legacy IPC to POSIX"
CONDITION TEST_posix_shm AND TEST_posix_sem AND (
FEATURE_ipc_posix OR (APPLE AND QT_FEATURE_appstore_compliant)
OR NOT (TEST_sysv_shm AND TEST_sysv_sem)
)
)
qt_feature_definition("ipc_posix" "QT_POSIX_IPC")

>From the cmake output, we should have:
TEST_posix_shm = ON
TEST_posix_sem = ON
TEST_sysv_shm = OFF
TEST_sysv_sem = OFF

So this condition should have been TRUE. But isn't.

BTW, the iOS build said:
   Defaulting legacy IPC to POSIX . yes

So the middle condition of appstore-compliance did work.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



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

Re: [Development] INTEGRITY help needed: IPC & QT_CONFIG weirdness

[Niclas Rosenvik]

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 to include whether the key was
> enabled and it was indeed NOT enabled:
> 
>  -- Performing Test HAVE_sysv_shm
>  -- Performing Test HAVE_sysv_shm - Failed
>  -- Performing Test HAVE_sysv_sem
>  -- Performing Test HAVE_sysv_sem - Failed
>  -- Performing Test HAVE_posix_shm
>  -- Performing Test HAVE_posix_shm - Success
>  -- Performing Test HAVE_posix_sem
>  -- Performing Test HAVE_posix_sem - Success
> [...]
>Defaulting legacy IPC to POSIX . no
> 
> This is the last remaining failure in the patchset. If no one
> suggests a fix, I'll create a bug report for Someone Else™ and
> QEXPECT_FAIL the issue.
> 

Hi Thiago, I just looked at the build log at:
https://testresults.qt.io/coin/api/results/qt/qtbase/31eb60ef6fa413035971e47cc3f0eccaeba2a4dd/LinuxUbuntu_20_04x86_64QNXQNX_710arm64GCCqtci-linux-Ubuntu-20.04-x86_64-50-ab8bebDisableTests_UseConfigure/fbbf955d4168c54abbfb4dde4ba71ab3b3195ce0/build_1679395838/log.txt.gz

It includes this:
/CMakeFiles/Core.dir/cmake_pch.hxx 
-Wp,-MD,src/corelib/CMakeFiles/Core.dir/ipc/qsharedmemory_posix.cpp.o.d 
-Wp,-MT,src/corelib/CMakeFiles/Core.dir/ipc/qsharedmemory_posix.cpp.o 
-Wp,-MF,src/corelib/CMakeFiles/Core.dir/ipc/qsharedmemory_posix.cpp.o.d -o 
src/corelib/CMakeFiles/Core.dir/ipc/qsharedmemory_posix.cpp.o -c 
/home/qt/work/qt/qtbase/src/corelib/ipc/qsharedmemory_posix.cpp
agent:2022/11/06 03:52:38 build.go:394: In file included from 
/home/qt/work/qt/qtbase/build/target/include/QtCore/qtipccommon.h:1,
agent:2022/11/06 03:52:38 build.go:394:  from 
/home/qt/work/qt/qtbase/src/corelib/ipc/qsharedmemory.h:7,
agent:2022/11/06 03:52:38 build.go:394:  from 
/home/qt/work/qt/qtbase/src/corelib/ipc/qsharedmemory_posix.cpp:6:
agent:2022/11/06 03:52:38 build.go:394: 
/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'
agent:2022/11/06 03:52:38 build.go:394:  Type type : 15;
agent:2022/11/06 03:52:38 build.go:394:  ^~
agent:2022/11/06 03:52:39 build.go:394: [277/1163]
/opt/qnx710/host/linux/x86_64/usr/bin/q++ -Vgcc_ntoaarch64le
-Wc,-isysroot,/opt/qnx710/target/qnx7 -lang-c++ -DCore_EXPORTS
-DPCRE2_CODE_UNIT_WIDTH=16 -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_UP_TO=0x05 

Is this the error that causes QNativeIpcKey::Type::SystemV to be the
value you mentioned?
warning: 'QNativeIpcKey::TypeAndFlags::type' is too small to hold all
values of 'enum class QNativeIpcKey::Type'

I don't know how to fix it but it might be a step in the right
direction, if it is the error.

Regards,
Niclas Rosenvik
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY help needed: IPC & QT_CONFIG weirdness

[Thiago Macieira]

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:

 -- Performing Test HAVE_sysv_shm
 -- Performing Test HAVE_sysv_shm - Failed
 -- Performing Test HAVE_sysv_sem
 -- Performing Test HAVE_sysv_sem - Failed
 -- Performing Test HAVE_posix_shm
 -- Performing Test HAVE_posix_shm - Success
 -- Performing Test HAVE_posix_sem
 -- Performing Test HAVE_posix_sem - Success
[...]
   Defaulting legacy IPC to POSIX . no

This is the last remaining failure in the patchset. If no one suggests a fix, 
I'll create a bug report for Someone Else™ and QEXPECT_FAIL the issue.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



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

Re: [Development] INTEGRITY help needed: IPC & QT_CONFIG weirdness

[Thiago Macieira]

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/qtbase/tasks/1679395790

In the build, the log says:
 -- Performing Test HAVE_sysv_shm
 -- Performing Test HAVE_sysv_shm - Failed
 -- Performing Test HAVE_sysv_sem
 -- Performing Test HAVE_sysv_sem - Failed
 -- Performing Test HAVE_posix_shm
 -- Performing Test HAVE_posix_shm - Success
 -- Performing Test HAVE_posix_sem
 -- Performing Test HAVE_posix_sem - Success

which is the expected condition. This should have triggered the macro 
QT_POSIX_IPC, given configure.cmake:

qt_feature("ipc_posix"
LABEL "Using POSIX IPC"
CONDITION TEST_posix_shm AND TEST_posix_sem AND (
FEATURE_ipc_posix OR (APPLE AND QT_FEATURE_appstore_compliant)
OR NOT (TEST_sysv_shm AND TEST_sysv_sem)
)
)
qt_feature_definition("ipc_posix" "QT_POSIX_IPC")

And yet, when tst_qsharedmemory started, it printed the debug message:

QDEBUG : tst_QSharedMemory::initTestCase() Default key type is 
QNativeIpcKey::Type::SystemV and legacy key type is 
QNativeIpcKey::Type::SystemV

Both key types should have been POSIX, given:

static constexpr Type DefaultTypeForOs =
#ifdef Q_OS_WIN
Type::Windows
#elif !defined(QT_POSIX_IPC)
Type::SystemV
#else
Type::PosixRealtime
#endif
;

inline auto QNativeIpcKey::legacyDefaultTypeForOs() noexcept -> Type
{
#if defined(Q_OS_WIN)
return Type::Windows;
#elif defined(QT_POSIX_IPC)
return Type::PosixRealtime;
#elif defined(Q_OS_DARWIN)
return defaultTypeForOs_internal();
#else
return Type::SystemV;
#endif
}

But neither is, which tells me that QT_POSIX_IPC wasn't defined. What's 
happening?

Maybe it got defined but not added to qconfig.h? I changed the conditions for 
the feature, but not anything else, so it should have remained public (and I 
did make a local test stting FEATURE_ipc_posix).

This time, it can't be a missing #include. qtipccommon.h includes qglobal.h, 
which includes qtconfigmacros.h, which includes qconfig.h and qtcore-config.h.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



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

[Development] INTEGRITY help needed: IPC & QT_CONFIG weirdness

[Thiago Macieira]

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:

https://codereview.qt-project.org/c/qt/qtbase/+/438438/1

and I'm not even done creating content. The big advantage of this patch set is 
to enable BOTH SystemV and POSIX at the same time on Unix systems, which is 
impotant for macOS so the same build of Qt can be used for regular 
applications and those distributed via the App Store.

My issue is that INTEGRITY isn't cooperating. I've already fixed a number of 
WASM problems by running the CI, but now I'm stumped. I need someone to figure 
out what went wrong.

I've been using https://codereview.qt-project.org/c/qt/qtbase/+/437953 as a 
squashed commit of all the content so I can push it through the CI and get 
results. In the last run
https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1679359812

the build log said:
 -- Performing Test HAVE_sysv_shm
 -- Performing Test HAVE_sysv_shm - Failed
 -- Performing Test HAVE_sysv_sem
 -- Performing Test HAVE_sysv_sem - Failed
 -- Performing Test HAVE_posix_shm
 -- Performing Test HAVE_posix_shm - Failed
 -- Performing Test HAVE_posix_sem
 -- Performing Test HAVE_posix_sem - Success

So this means it enabled one of the backends for QSystemSemaphore, like WASM. 
Now, I have no clue whether the APIs *work* at runtime, but that's not 
important. The code can deal with that -- I developed it because posix_sem is 
also Success with MinGW, but the APIs always fail at runtime.

But unlike WASM and MinGW, the build fails:

 "/home/qt/work/qt/qtbase/src/corelib/ipc/qsystemsemaphore_posix.cpp", line 
14: warning #193-D: zero used for undefined preprocessing identifier ""
   #if QT_CONFIG(posix_sem)
   ^
 "/home/qt/work/qt/qtbase/src/corelib/ipc/qsystemsemaphore_posix.cpp", line 
14: error #39: division by zero
   #if QT_CONFIG(posix_sem)
   ^

QT_CONFIG is defined in such a way that if you used a configure name that isn't 
known, you get a division by zero:

#define QT_CONFIG(feature) (1/QT_FEATURE_##feature == 1)

This tells us we QT_FEATURE_posix_sem isn't defined. Why?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



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

Re: [Development] INTEGRITY

[Tuukka Turunen]

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 may even want to 
move items from the wiki to docs. It is fine to have wiki to support, but there 
is high risk of wiki content to become outdated.

Yours,

Tuukka

On 20/09/2019, 12.03, "Development on behalf of Giuseppe D'Angelo via 
Development"  wrote:

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 guidelines; security policies) 
as well as for unofficial, community-driven content. Nobody knows the 
official status of any individual page just by looking at it.

So now there's information on the wiki AND in the docs about Qt on 
INTEGRITY, they both appear on Google search results, and of course 
they're in contradiction with each other (wiki says that Qt on INTEGRITY 
is community-driven, docs say it's officially supported; wiki does a 
shared build, docs say only static builds work).

My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



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

Re: [Development] INTEGRITY

[Giuseppe D'Angelo via Development]

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 guidelines; security policies) 
as well as for unofficial, community-driven content. Nobody knows the 
official status of any individual page just by looking at it.


So now there's information on the wiki AND in the docs about Qt on 
INTEGRITY, they both appear on Google search results, and of course 
they're in contradiction with each other (wiki says that Qt on INTEGRITY 
is community-driven, docs say it's officially supported; wiki does a 
shared build, docs say only static builds work).


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Ville Voutilainen]

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.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Allan Sandfeld Jensen]

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
> > >>> 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 in its existing constexpr implementation. That's
> > > different. MSVC 2015 officially supported constexpr, but we turned it
> > > off
> > > for them because it was too buggy.
> > 
> >  it still means that we can't require core language
> > conformity from our compilers. And we're talking about C++11's
> > constexpr, not C++14's.
> 
> I've just checked our changelogs and we've never raised the minimum version
> of GCC from 4.7. That means we can't officially depend on anything that GCC
> 4.8 added to the Core Language. They are:
> 
> - attributes
> - alignas & alignof
> - inheriting constructors
> - thread_local
> - ref qualifiers (4.8.1)
> 
> Attributes is a non-issue because we have __has_cpp_attribute /
> QT_HAS_ATTRIBUTE so we end up with macros for most attributes anyway.
> Alignas and alignof are also non-issues because they're rare enough.
> 
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.

Allan



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

Re: [Development] INTEGRITY

[Tuukka Turunen]

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 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.), apply it, else
> 4. drop Integrity support (or update to a newer version) ASAP (for Qt 
> 5.15 if not 5.14).
>
5. Cleanup the wiki page: https://wiki.qt.io/INTEGRITY_Platform

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


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

Re: [Development] INTEGRITY

[André Pönitz]

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 Integrity.
> 
> It's already in Qt, and used:
> 
> > https://code.woboq.org/qt5/qtbase/src/corelib/tools/qarraydata.h.html#_M/Q_ARRAY_LITERAL_IMPL
> 
> Revocation of Q_CONSTEXPR is not so simple, as it's a source incompatible
> change.

It's a fairly safe assumption that given a choice of a SiC change and completely
dropping a platform most users of that platform would prefer the SiC change.

> (It's one of the reasons why stdlib implementors are not allowed to
> plaster constexpr unless the Standard says so.) It might work in the case in
> question, for which I've already asked for help twice in a few months
> (again: I don't have any access to INTEGRITY). It will just not work for
> other cases where you do want a constant expression, bringing us back to
> square one.

The context was dropping support for INTEGRITY, not "other cases".

Andre'


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

Re: [Development] INTEGRITY

[Thiago Macieira]

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.
> >> 
> >> Not really, it also fails on constexpr:
> >> 
> >> https://codereview.qt-project.org/c/qt/qtbase/+/264550
> > 
> > No, it has a bug in its existing constexpr implementation. That's
> > different. MSVC 2015 officially supported constexpr, but we turned it off
> > for them because it was too buggy.
> 
>  it still means that we can't require core language
> conformity from our compilers. And we're talking about C++11's
> constexpr, not C++14's.

I've just checked our changelogs and we've never raised the minimum version of 
GCC from 4.7. That means we can't officially depend on anything that GCC 4.8 
added to the Core Language. They are:

- attributes
- alignas & alignof
- inheriting constructors
- thread_local
- ref qualifiers (4.8.1)

Attributes is a non-issue because we have __has_cpp_attribute / 
QT_HAS_ATTRIBUTE so we end up with macros for most attributes anyway. Alignas 
and alignof are also non-issues because they're rare enough.

Inheriting constructors I'm not sure. It might be getting used without anyone 
noticing.

Ref qualifiers I know the few places that have them are still under #ifdef and 
thus compat builds.

And thread_local cannot be used because of MinGW (GCC and Clang). See the 
thread on this subject.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] INTEGRITY

[Thiago Macieira]

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 the available options.
> 
> It's not so easy: I, for once, don't have access to INTEGRITY to do any
> a priori evaluation of the technical feasibility of a solution.

And it's now even further behind, relatively speaking.

Marc wrote:
> If you would
> have a look at how much complexity is taken out of the Qt implementation
> of QWaitCondition by simply implementing it on top of the std one, incl.
> deleting a rather recent change for just Android, it should be obvious
> how this hurts maintainability of Qt. I know Thiago revels in such
> details

Three days ago, I did an investigation of libc++ and MSVC's 
std::condition_variable to see whether using wait_for() or wait_until() was 
better, minimising the number of calls to get the current system time. I wrote 
to Marc that wait_until() was better in both and showed the libc++ code to 
prove it, but had to write that I couldn't paste the MSVC code.

Since yesterday, I can:
https://devblogs.microsoft.com/cppblog/open-sourcing-msvcs-stl/ [*]
https://github.com/microsoft/STL

So all the Standard Libraries we depend on can be freely studied for 
performance and shortcomings and we can even submit fixes if we feel like it. 
EXCEPT for Integrity.

[*] Note the blog author's initials :-)
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] INTEGRITY

[Thiago Macieira]

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-released
> 
> > "we require a C++11[-]compliant compiler to build [...] Qt"
> 
> The std library is not optional, unless you mean that Qt explicitly
> targets free-standing implementations. That, however, is not mentioned.
> When we dropped support for pre-C++98-compilers in 5.0, we also removed
> -no-stl, because that's natural. There's a technical distinction between
> the compiler and the std library, but from the POV of the standard, in
> hosted environments, there isn't.

You're mis-remembering or mis-interpreting the Qt 5.0 decision. The -no-stl 
option was removed because we decided in 2012 that a C++98-compliant Standard 
Library is required.

The wording in the Qt 5.7 changelog was:
 - Starting with Qt 5.7, Qt requires a C++11 compiler with support for
   C++11 atomics. This affects user code too: Qt headers no longer compile
   with a C++98 compiler.

The Qt 5.6 and 5.7 wording was even more restrictive:
 - Qt 5.7 will begin requiring certain C++11 features in order to
   compile.

We've NEVER meant we required the entire C++11 core language and much less the 
entire Standard Library. Up until Qt 5.12, we didn't require constexpr in at 
least one compiler. We STILL don't require C++11's ref-qualified member 
functions!

We also know that the Standard Library lags behind the Core Language in the 
implementations. We have to be realist and know what we can and cannot depend 
on.

And I've said in multiple reviews that the use of C++11 standard library 
features needed to be tested. I've asked multiple times that we confirm which 
features are safe to use in all our minimum implementations. Just search 
Gerrit and this mailing list.

> QNX was a case where an older library (by a different vendor) shipped
> with a newer GCC, and that limited the use of library features in Qt,
> but that particular platform is now gone, and if Integrity has the same
> problem as that QNX toolchain had, it should have been removed along
> with it. Otherwise, we could've kept QNX along for the ride with no
> extra cost to the Qt project.

I agree with the "extra cost" argument. Platforms that don't move fast enough 
impose a burden on us. I do like your cleanups in QtTest, for example -- we've 
always had the rule that QtTest should use the least amount of Qt, so that we 
can test buggy Qt in the first place.

> I think we should be way past caring for non-conforming platforms. We
> decided to use SD-6 macros for post-C++14 feature detection, even
> thought that meant that none of the features were detected for MSVC, a
> much more important platform that Integrity.

Correct, but we can't depend on C++14 anyway, so that meant little to our 
functionality. Everything in Qt continued to compile and work even without 
those macros.

That's a whole level of difference from dropping features or an entire 
platform.

Still, it's a decision we can make. I'm not opposed to it, as I have been 
bitten by Integrity's compiler shortcomings before (see QRandomGenerator's 
integration log). But it's a *decision* to *change* our policy.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] INTEGRITY

[Giuseppe D'Angelo via Development]

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/src/corelib/tools/qarraydata.h.html#_M/Q_ARRAY_LITERAL_IMPL


Revocation of Q_CONSTEXPR is not so simple, as it's a source 
incompatible change. (It's one of the reasons why stdlib implementors 
are not allowed to plaster constexpr unless the Standard says so.) It 
might work in the case in question, for which I've already asked for 
help twice in a few months (again: I don't have any access to 
INTEGRITY). It will just not work for other cases where you do want a 
constant expression, bringing us back to square one.


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Kai Pastor, DG0YT]

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.), apply it, else
4. drop Integrity support (or update to a newer version) ASAP (for Qt 
5.15 if not 5.14).



5. Cleanup the wiki page: https://wiki.qt.io/INTEGRITY_Platform

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

Re: [Development] INTEGRITY

[Kyle Edwards via Development]

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

Kyle
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[André Pönitz]

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 
> > the
> > available options.
> 
> It's not so easy: I, for once, don't have access to INTEGRITY to do any a
> priori evaluation of the technical feasibility of a solution.

Me neither. 
 
> I can test and evaluate the other platforms, though. My webgradient patch
> will improve the situation on *ALL* platforms because it removes (quoting):
> 
> > * the binary json representation from QtGui's resources (~4KB
> > compressed, ~50KB uncompressed)
> > * the overhead of reading from the JSON for each used web
> > gradient;
> > * the startup costs of registering the webgradients in the
> > resources;
> > * all the overhead of mutex locking when building such
> > gradients;
> > * all the runtime memory allocations to load, parse and cache
> > the web gradients (including the memory + CPU spike on first
> > load due to the uncompression of the JSON data, as well as a
> > couple of deep copies).
> 
> But it cannot go in in Qt 5 because INTEGRITY does not implement C++11's
> constexpr.

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.

> Is it worth it? YES.

That's a valid opinion.

However, right now this looks to me like that you could have your performance
benefits for webgradients without Qt as a whole dropping support for INTEGRITY.

Andre'

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

Re: [Development] INTEGRITY

[Giuseppe D'Angelo via Development]

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 priori evaluation of the technical feasibility of a solution.


I can test and evaluate the other platforms, though. My webgradient 
patch will improve the situation on *ALL* platforms because it removes 
(quoting):



* the binary json representation from QtGui's resources (~4KB
compressed, ~50KB uncompressed)
* the overhead of reading from the JSON for each used web
gradient;
* the startup costs of registering the webgradients in the
resources;
* all the overhead of mutex locking when building such
gradients;
* all the runtime memory allocations to load, parse and cache
the web gradients (including the memory + CPU spike on first
load due to the uncompression of the JSON data, as well as a
couple of deep copies).


But it cannot go in in Qt 5 because INTEGRITY does not implement C++11's 
constexpr.


Is it worth it? YES.

My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[André Pönitz]

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, QWaitCondition is a
> condition_variabe_any and thus has inherently and unavoidably more overhead
> than condition_variable + mutex. There is no justification to add #ifdefs
> for all the places that QWaitCondition is used unconditionally now, so
> either we don't get the order-of-magnitude improvement on our main platform,
> Windows, or we need to introduce a private QtPrivate::condition_variable as
> an inline wrapper around condition_variable + mutex or, for Integrity,
> QWaitCondition + QMutex, which we need to replace once more with
> std::condition_variable + mutex if Integrity is fixed. Is it worth it,

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

But you entered the discussion _again_ with _your_ answer, stating _again_
that "we" "would like to replace it".

Can you please try to use a less overbearing approach? Like, presenting the
options, stating your personal opinion on their respective values, give people 
the
impression they have a chance to give their views, and when the dust has 
settled,
give the impression of making an educated guess on the result and "decide" 
_then_?

"Thank you."

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

Re: [Development] INTEGRITY

[Ville Voutilainen]

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 QWaitCondition
> was not compiled for Integrity? I'm looking, but I still don't see it.
> AFICT, it's using the generic Unix version, iow: pthread_cond_t, but...
> How is pthread_cond_t implemented on Integrity if the kernel doesn't
> support the concept?

Beats me; I'm mostly relaying information that was provided to me.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Mutz, Marc via Development]

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 is "so far behind all the other 
supported platforms, as well as its own claim of conformance, that the 
question must be asked why it's still supported".


I was, indeed, referring to the C++ support by GHS, not to the Qt 
functionality.



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 QWaitCondition 
was not compiled for Integrity? I'm looking, but I still don't see it. 
AFICT, it's using the generic Unix version, iow: pthread_cond_t, but... 
How is pthread_cond_t implemented on Integrity if the kernel doesn't 
support the concept?



Newer kernels do, and the version we use has a patch
available for this, it's on its way into our hands. We are most likely
going
to consider upgrading the INTEGRITY version we use in the CI, but none
of that will happen fast enough to be worth disturbing the release
proceedings of 5.14.


Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Ville Voutilainen]

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 
> platforms, as well as its own claim of conformance, that the question must be 
> asked why it's still supported". Like any RTOS platform, there are known 
> restrictions in the functionality supported on INTEGRITY: 
> https://doc.qt.io/qt-5/integrity.html. If there are additional restrictions, 
> those should be added to the platform notes. There also may be work arounds 
> needed for some items, as suggested. In case of issues with the OS or the 
> compiler, it is also possible to report a bug to Green Hills.

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. Newer kernels do, and the version we use has a patch
available for this, it's on its way into our hands. We are most likely
going
to consider upgrading the INTEGRITY version we use in the CI, but none
of that will happen fast enough to be worth disturbing the release
proceedings of 5.14.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Ville Voutilainen]

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.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Tuukka Turunen]

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 question must be 
asked why it's still supported". Like any RTOS platform, there are known 
restrictions in the functionality supported on INTEGRITY: 
https://doc.qt.io/qt-5/integrity.html. If there are additional restrictions, 
those should be added to the platform notes. There also may be work arounds 
needed for some items, as suggested. In case of issues with the OS or the 
compiler, it is also possible to report a bug to Green Hills. 

Yours,

Tuukka


On 19/09/2019, 12.21, "Development on behalf of Mutz, Marc via Development" 
 
wrote:

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 principle a pure cleanup patch doing
> internal refactoring. It wouldn’t be too difficult (though maybe not
> very nice looking though) to keep the old code for INTEGRITY only.
> It’s been tested and we know it works.
> 
> We’ve been applying workarounds for missing support for some C++11
> features in other toolchains/compilers as well. We kept the Atomic
> implementations for MSVC around for exactly the same reasons.

That may work for the series of patches that implements QWaitCondition 
using std::condition_variable, which, indeed, is just a cleanup patch.

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, QWaitCondition is a condition_variabe_any and thus has 
inherently and unavoidably more overhead than condition_variable + 
mutex. There is no justification to add #ifdefs for all the places that 
QWaitCondition is used unconditionally now, so either we don't get the 
order-of-magnitude improvement on our main platform, Windows, or we need 
to introduce a private QtPrivate::condition_variable as an inline 
wrapper around condition_variable + mutex or, for Integrity, 
QWaitCondition + QMutex, which we need to replace once more with 
std::condition_variable + mutex if Integrity is fixed. Is it worth it, 
for a buggy platform that's in the process of being fixed? I'm not sure 
it would be...

In addition, as Peppe noticed, this is not the first time Integrity has 
shown up as a problematic platform, and it now is so far behind all the 
other supported platforms, as well as its own claim of conformance, that 
the question must be asked why it's still supported.

Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


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

Re: [Development] INTEGRITY

[Lars Knoll]

> 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 constexpr:
>>> 
>>> https://codereview.qt-project.org/c/qt/qtbase/+/264550
>> No, it has a bug in its existing constexpr implementation. That's different.
>> MSVC 2015 officially supported constexpr, but we turned it off for them
>> because it was too buggy.
> 
>  it still means that we can't require core language 
> conformity from our compilers. And we're talking about C++11's constexpr, not 
> C++14’s.

Yes, and I believe we’ll continue to have to live with workarounds in some 
places. In practice, what we can use is defined by the set of compilers we 
support. Being able to take new features into use is often only possible after 
dropping certain compilers/compiler versions.

Cheers,
Lars

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

Re: [Development] INTEGRITY

[Giuseppe D'Angelo via Development]

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 in its existing constexpr implementation. That's different.
MSVC 2015 officially supported constexpr, but we turned it off for them
because it was too buggy.


 it still means that we can't require core language 
conformity from our compilers. And we're talking about C++11's 
constexpr, not C++14's.


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Mutz, Marc via Development]

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 principle a pure cleanup patch doing
internal refactoring. It wouldn’t be too difficult (though maybe not
very nice looking though) to keep the old code for INTEGRITY only.
It’s been tested and we know it works.

We’ve been applying workarounds for missing support for some C++11
features in other toolchains/compilers as well. We kept the Atomic
implementations for MSVC around for exactly the same reasons.


That may work for the series of patches that implements QWaitCondition 
using std::condition_variable, which, indeed, is just a cleanup patch.


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, QWaitCondition is a condition_variabe_any and thus has 
inherently and unavoidably more overhead than condition_variable + 
mutex. There is no justification to add #ifdefs for all the places that 
QWaitCondition is used unconditionally now, so either we don't get the 
order-of-magnitude improvement on our main platform, Windows, or we need 
to introduce a private QtPrivate::condition_variable as an inline 
wrapper around condition_variable + mutex or, for Integrity, 
QWaitCondition + QMutex, which we need to replace once more with 
std::condition_variable + mutex if Integrity is fixed. Is it worth it, 
for a buggy platform that's in the process of being fixed? I'm not sure 
it would be...


In addition, as Peppe noticed, this is not the first time Integrity has 
shown up as a problematic platform, and it now is so far behind all the 
other supported platforms, as well as its own claim of conformance, that 
the question must be asked why it's still supported.


Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Heikki Halmet]

Hi,

Aapo is on sick leave today.

<< There is a flag in Coin to build tests are module build time instead of 
before testing. Perhaps that can somehow be combined with the DisableTests 
feature flag in Coin. Aapo, do << you think that would be possible?
Yes, this one is already done and merged: 
https://bugreports.qt.io/browse/COIN-174 (Create test binaries as a part of 
building phase)
We still need to fix this one https://bugreports.qt.io/browse/COIN-381 (Out of 
source builds are broken), which is currently under work.


Br
Heikki


From: Development  On Behalf Of Simon 
Hausmann
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 for 
every qtbase integration.


There is a flag in Coin to build tests are module build time instead of before 
testing. Perhaps that can somehow be combined with the DisableTests feature 
flag in Coin. Aapo, do you think that would be possible?

That said, while I've seen this type of failure before (change went into qtbase 
that affected only static builds and only visible at link time), it happens - 
in my experience - perhaps twice a year and it _does_ get noticed fairly 
quickly after all. So I'm not sure if it's worth a hack in the CI system.


Simon

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Giuseppe D'Angelo via Development 
mailto:development@qt-project.org>>
Sent: Wednesday, September 18, 2019 14:00
To: development@qt-project.org<mailto:development@qt-project.org> 
mailto:development@qt-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 suggestion: build (if not even *run*) the autotests?

My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com<mailto:giuseppe.dang...@kdab.com> 
| Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Lars Knoll]

> 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 seems to be Ville.
> 
>> 2. That maintainer should either find the missing linker flag, or file
>> a bug with Integrity
> 
> It looks like a bug, and a report has been filed
> 
>> 3. If there's a work-around (providing those missing functions in Qt,
>> e.g.), apply it, else
> 
> A work-around (or fix) is in the works by the vendor, but won't be available 
> in time for 5.14, ...
> 
>> 4. drop Integrity support (or update to a newer version) ASAP (for Qt
>> 5.15 if not 5.14).
> 
> ... but for 5.15.
> 
> Which reduces all these to the following request:
> 
> - temporarily drop Integrity from 5.15 CI until the fix is there

Not a good idea because we don’t know whether a fix will come in time and 
dropping it from CI can lead to other platform regressions. You’re potentially 
adding lots of work for other people to get your one patch through. And as said 
there’s an option of working around by simply keeping the old code for 
INTEGRITY only if you really want it in 5.15.
> 
> If that is not possible, I hereby request a feature branch for this (say, 
> wip/wait_condition), so work can continue and either be merged into 5.15 or 
> 6, depending on availability of the fix.

Why? If the above is too much work, simply drop the feature for 5.15 and go 
straight to 6.0.

Lars

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

Re: [Development] INTEGRITY

[Mutz, Marc via Development]

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, or file
a bug with Integrity


It looks like a bug, and a report has been filed


3. If there's a work-around (providing those missing functions in Qt,
e.g.), apply it, else


A work-around (or fix) is in the works by the vendor, but won't be 
available in time for 5.14, ...



4. drop Integrity support (or update to a newer version) ASAP (for Qt
5.15 if not 5.14).


... but for 5.15.

Which reduces all these to the following request:

- temporarily drop Integrity from 5.15 CI until the fix is there

If that is not possible, I hereby request a feature branch for this 
(say, wip/wait_condition), so work can continue and either be merged 
into 5.15 or 6, depending on availability of the fix.


Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Lars Knoll]

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 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 in its existing constexpr implementation. That's different.
MSVC 2015 officially supported constexpr, but we turned it off for them
because it was too buggy.
Are we sure to be running the latest version of the GHS compiler?
According to INTEGRITY documentation: "Namespace member
std::condition_variable is not supported, along with any library functions
related to it (for example, std::notify_all_at_thread_exit)."
So there's no way out of this.
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-released
"we require a C++11[-]compliant compiler to build [...] Qt"

The std library is not optional, unless you mean that Qt explicitly targets 
free-standing implementations. That, however, is not mentioned. When we dropped 
support for pre-C++98-compilers in 5.0, we also removed -no-stl, because that's 
natural. There's a technical distinction between the compiler and the std 
library, but from the POV of the standard, in hosted environments, there isn't.

QNX was a case where an older library (by a different vendor) shipped with a 
newer GCC, and that limited the use of library features in Qt, but that 
particular platform is now gone, and if Integrity has the same problem as that 
QNX toolchain had, it should have been removed along with it. Otherwise, we 
could've kept QNX along for the ride with no extra cost to the Qt project.

I think we should be way past caring for non-conforming platforms. We decided 
to use SD-6 macros for post-C++14 feature detection, even thought that meant 
that none of the features were detected for MSVC, a much more important 
platform that Integrity.

But that didn’t break MSVC. It simply meant that they didn’t get some new 
features or performance improvements. So there’s a huge difference here.

The worst thing is that INTEGRITY claims support for C++14 on it's homepage, 
even citing the official name of the standard. It *does* provide 
std::condition_variable, proven by the fact that the header exists, can be 
included and use of std::condition_variable is compiled without error, so it's 
clearly positioning itself as a hosted environment, not a free-standing one. 
That means that std::condition_variable needs to be available, or else you're 
non-conforming. If you're advertising with conformance, but are in fact 
nonconforming, that's misleading advertising, which, at least in EU law, is 
punishable.

That, and the fact that the pthreads version we're replacing in QWaitCondition 
was working before, makes me think that there can be no reason not to provide 
std::condition_variable, because it totally models pthread's condition 
variables, so either we're using an old version of the tool-chain, or the OS, 
or we're indeed just missing a linker flag.

But no-one seems to know anything (and there's _still_ no maintainer for the 
platform listed in the wiki). The best reaction I get is to revert the patch 
that introduced use of std::condition_variable. If you would have a look at how 
much complexity is taken out of the Qt implementation of QWaitCondition by 
simply implementing it on top of the std one, incl. deleting a rather recent 
change for just Android, it should be obvious how this hurts maintainability of 
Qt. I know Thiago revels in such details, but there're also those Qt devs who 
cannot bear the presence of a find_if. What would the latter half have to say 
about the four or so different mutex implementations? While the mutex 
implementations can be argued to actually be worth it (though they could be 
reduced to two: futex and std::mutex), because futex outperforms std::mutex, 
QWaitCondition is _much_ slower (on Windows an order of magnitude) than 
std::condition_variable.

Standing in the way of Qt maintainability in this way should disqualify 
INTEGRITY as a supported platform until it's resolved.

So, I update my requests:

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.), 
apply it, else

I agree that we should have a named maintainer for the platform.

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 

Re: [Development] INTEGRITY

[Mutz, Marc via Development]

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 fails on constexpr:

https://codereview.qt-project.org/c/qt/qtbase/+/264550


No, it has a bug in its existing constexpr implementation. That's 
different.

MSVC 2015 officially supported constexpr, but we turned it off for them
because it was too buggy.

Are we sure to be running the latest version of the GHS compiler?


According to INTEGRITY documentation: "Namespace member
std::condition_variable is not supported, along with any library 
functions

related to it (for example, std::notify_all_at_thread_exit)."

So there's no way out of this.


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

"we require a C++11[-]compliant compiler to build [...] Qt"


The std library is not optional, unless you mean that Qt explicitly 
targets free-standing implementations. That, however, is not mentioned. 
When we dropped support for pre-C++98-compilers in 5.0, we also removed 
-no-stl, because that's natural. There's a technical distinction between 
the compiler and the std library, but from the POV of the standard, in 
hosted environments, there isn't.


QNX was a case where an older library (by a different vendor) shipped 
with a newer GCC, and that limited the use of library features in Qt, 
but that particular platform is now gone, and if Integrity has the same 
problem as that QNX toolchain had, it should have been removed along 
with it. Otherwise, we could've kept QNX along for the ride with no 
extra cost to the Qt project.


I think we should be way past caring for non-conforming platforms. We 
decided to use SD-6 macros for post-C++14 feature detection, even 
thought that meant that none of the features were detected for MSVC, a 
much more important platform that Integrity.


The worst thing is that INTEGRITY claims support for C++14 on it's 
homepage, even citing the official name of the standard. It *does* 
provide std::condition_variable, proven by the fact that the header 
exists, can be included and use of std::condition_variable is compiled 
without error, so it's clearly positioning itself as a hosted 
environment, not a free-standing one. That means that 
std::condition_variable needs to be available, or else you're 
non-conforming. If you're advertising with conformance, but are in fact 
nonconforming, that's misleading advertising, which, at least in EU law, 
is punishable.


That, and the fact that the pthreads version we're replacing in 
QWaitCondition was working before, makes me think that there can be no 
reason not to provide std::condition_variable, because it totally models 
pthread's condition variables, so either we're using an old version of 
the tool-chain, or the OS, or we're indeed just missing a linker flag.


But no-one seems to know anything (and there's _still_ no maintainer for 
the platform listed in the wiki). The best reaction I get is to revert 
the patch that introduced use of std::condition_variable. If you would 
have a look at how much complexity is taken out of the Qt implementation 
of QWaitCondition by simply implementing it on top of the std one, incl. 
deleting a rather recent change for just Android, it should be obvious 
how this hurts maintainability of Qt. I know Thiago revels in such 
details, but there're also those Qt devs who cannot bear the presence of 
a find_if. What would the latter half have to say about the four or so 
different mutex implementations? While the mutex implementations can be 
argued to actually be worth it (though they could be reduced to two: 
futex and std::mutex), because futex outperforms std::mutex, 
QWaitCondition is _much_ slower (on Windows an order of magnitude) than 
std::condition_variable.


Standing in the way of Qt maintainability in this way should disqualify 
INTEGRITY as a supported platform until it's resolved.


So, I update my requests:

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.), apply it, else
4. drop Integrity support (or update to a newer version) ASAP (for Qt 
5.15 if not 5.14).


Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Giuseppe D'Angelo via Development]

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 
configure, so it was as simple as dropping that. Running make check 
would be the extra mile.


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Oswald Buddenhagen]

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 few days ago.

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

Re: [Development] INTEGRITY

[Simon Hausmann]

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 for 
every qtbase integration.


There is a flag in Coin to build tests are module build time instead of before 
testing. Perhaps that can somehow be combined with the DisableTests feature 
flag in Coin. Aapo, do you think that would be possible?

That said, while I've seen this type of failure before (change went into qtbase 
that affected only static builds and only visible at link time), it happens - 
in my experience - perhaps twice a year and it _does_ get noticed fairly 
quickly after all. So I'm not sure if it's worth a hack in the CI system.


Simon

From: Development  on behalf of Giuseppe 
D'Angelo via Development 
Sent: Wednesday, September 18, 2019 14:00
To: development@qt-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 suggestion: build (if not even *run*) the autotests?

My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] INTEGRITY

[Thiago Macieira]

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://codereview.qt-project.org/c/qt/qtbase/+/264550

No, it has a bug in its existing constexpr implementation. That's different. 
MSVC 2015 officially supported constexpr, but we turned it off for them 
because it was too buggy.

Are we sure to be running the latest version of the GHS compiler?

> According to INTEGRITY documentation: "Namespace member
> std::condition_variable is not supported, along with any library functions
> related to it (for example, std::notify_all_at_thread_exit)."
> 
> So there's no way out of this.

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] INTEGRITY

[Giuseppe D'Angelo via Development]

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 dropped when MSVC 2013 was?


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


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, atomics,
future/promise, and the use of the thread_local keyword.


So, is the CI just using a totally outdated toolchain?


More than likely we're just missing an -l flag or equivalent to link to the
necessary implementation. If that's the case, it's no different than libstdc++
which requires adding -lpthread to your link command-line.


From QTBUG-78450:


According to INTEGRITY documentation: "Namespace member std::condition_variable is 
not supported, along with any library functions related to it (for example, 
std::notify_all_at_thread_exit)."


So there's no way out of this.

My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Thiago Macieira]

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 required C++11 Standard Library. We've only required the core 
language and the integrity compiler does support it just fine.

> 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, atomics,
> > future/promise, and the use of the thread_local keyword.
> 
> So, is the CI just using a totally outdated toolchain?

More than likely we're just missing an -l flag or equivalent to link to the 
necessary implementation. If that's the case, it's no different than libstdc++ 
which requires adding -lpthread to your link command-line.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] INTEGRITY

[Giuseppe D'Angelo via Development]

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 | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Simon Hausmann]

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?
>
> 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 happily compiles std::condition_variable, it fails with a linker 
> error later. An error not detected in the CI until qt5 integration time.
>

That is quite unfortunate.


> 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?
>
The answer to how we got into this situation is that we simply have not 
used any of the types or features that aren't supported yet. I recall 
that during the course of Qt 5 developer we've quite often encountered 
missing C++11 features on compilers that otherwise claimed C++11 support.

As to your second question, I suppose the reason why Integrity wasn't 
removed from the list of supported platforms is that it has more users 
than MSVC 2013, when that was dropped.


> There's no maintainer listed for the platform in the Wiki (can we get 
> that fixed, please?), yet Ville tells me this is a 'gold platform' for 
> Qt releases.
>
> Can someone, please, square me how how Qt 6 should be based on C++17 
> if current INTEGRITY doesn't even support C++11?
>
For Qt 6 that, at the moment, implies dropping Integrity and adding it 
later. If you look at the qt5.git dev changes and the configurations 
there in particular, then you can see that Integrity is not there anymore.


> And can we please have a Qtbase CI that _actually_ tests INTEGRITY?
>
Every change submitted to qtbase is built with ghs and against the 
Integrity environment. What the current build coverage does not cover is 
creating an executable and therefore testing linkage. The first time 
this happens is during the build of declarative, where a target-tool is 
built. This means that especially configurations using static linkage, 
such as the Integrity build or iOS, receive their final "test coverage" 
in terms of linking after qtbase. To narrow it down even further, this 
is a problem that's limited to platforms where we just can't run any 
tests right now -- that applies to Integrity especially.

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?



Simon

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

Re: [Development] INTEGRITY

[Mutz, Marc via Development]

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, atomics,
future/promise, and the use of the thread_local keyword.


So, is the CI just using a totally outdated toolchain?

Thanks,
Marc


On 2019-09-18 12:29, Mutz, Marc via Development wrote:

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 happily compiles std::condition_variable, it fails with a linker
error later. An error not detected in the CI until qt5 integration
time.

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?

There's no maintainer listed for the platform in the Wiki (can we get
that fixed, please?), yet Ville tells me this is a 'gold platform' for
Qt releases.

Can someone, please, square me how how Qt 6 should be based on C++17
if current INTEGRITY doesn't even support C++11?

And can we please have a Qtbase CI that _actually_ tests INTEGRITY?

Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Development] INTEGRITY

[Mutz, Marc via Development]

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 
happily compiles std::condition_variable, it fails with a linker error 
later. An error not detected in the CI until qt5 integration time.


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?


There's no maintainer listed for the platform in the Wiki (can we get 
that fixed, please?), yet Ville tells me this is a 'gold platform' for 
Qt releases.


Can someone, please, square me how how Qt 6 should be based on C++17 if 
current INTEGRITY doesn't even support C++11?


And can we please have a Qtbase CI that _actually_ tests INTEGRITY?

Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY changes for 5.7

[Oswald Buddenhagen]

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 already but never got merged (partially because of the CI woes).
> > 
> 
> I support Rolland in this.
>
the series has been moved to 5.7.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] INTEGRITY changes for 5.7

[Robert Griebl]

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 merged (partially because of the CI woes).

This would cover all the patches with a positive code review status at
https://codereview.qt-project.org/#/q/owner:rolland%2540ghs.com+status:open,
n,z


I support Rolland in this. The patches were reviewed some time ago and were
fine. Rolland wasn't aware that he needed to keep pushing the Stage button...

This should bring Qt 5.7 to work on INTEGRITY, provided a C++11 compiler is
available for that platform.


+1


--
Robert Griebl
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
robert.gri...@pelagicore.com
www.pelagicore.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] INTEGRITY changes for 5.7

[Thiago Macieira]

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).
> 
> This would cover all the patches with a positive code review status at
> https://codereview.qt-project.org/#/q/owner:rolland%2540ghs.com+status:open,
> n,z

I support Rolland in this. The patches were reviewed some time ago and were 
fine. Rolland wasn't aware that he needed to keep pushing the Stage button...

This should bring Qt 5.7 to work on INTEGRITY, provided a C++11 compiler is 
available for that platform.

-- 
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] INTEGRITY changes for 5.7

[Blasche Alexander]

It never worked in the Qt5.x releases so far. For what it's worth I'd argue 
this is bugfixing for a non-working platform. 

Your gerrit reviews would have to be retargeted to 5.7 (A Gerrit admin can do 
that if that's the conclusion we come to in this thread). 

--
Alex


> -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 <cavendish...@gmail.com>
> Cc: development@qt-project.org
> Subject: Re: [Development] INTEGRITY changes for 5.7
> 
> Ideally i'd like to get those also in 5.7 indeed.
> 
> For 5.8/dev, there is no need for asking for an exception i guess, just 
> following
> the regular merge procedure would do just fine.
> 
> --Rolland
> 
> From: Liang Qi <cavendish...@gmail.com>
> Sent: Mar 2, 2016 08:28
> To: Rolland Dudemaine
> Cc: development@qt-project.org
> Subject: 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 <roll...@ghs.com
> <mailto:roll...@ghs.com> > 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).
> 
>   This would cover all the patches with a positive code review
> status at
>   https://codereview.qt-
> project.org/#/q/owner:rolland%2540ghs.com+status:open,n,z
> 
>   Thanks,
>   Best regards,
> 
>   --
>   --
>   Rolland Dudemaine   tel direct:+33 143 143 702
> <tel:%2B33%20143%20143%20702>
>   Green Hills Software   tel:+33 143 143 700
> <tel:%2B33%20143%20143%20700>
>   4 rue de la Pierre Leveemailto:roll...@ghs.com
> <mailto:roll...@ghs.com>
>   75011 Paris   fax: +33 143 143 707
> <tel:%2B33%20143%20143%20707>
>   France web: http://www.ghs.com
> <http://www.ghs.com>
>   --
> 
>   ___
>   Development mailing list
>   Development@qt-project.org <mailto:Development@qt-
> project.org>
>   http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> 
> 
> 
>   --
> 
>   http://www.qiliang.net

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

Re: [Development] INTEGRITY changes for 5.7

[Rolland Dudemaine]

Ideally i'd like to get those also in 5.7 indeed.

For 5.8/dev, there is no need for asking for an exception i guess, just 
following the regular merge procedure would do just fine.

--Rolland

From: Liang Qi <cavendish...@gmail.com>
Sent: Mar 2, 2016 08:28
To: Rolland Dudemaine
Cc: development@qt-project.org
Subject: 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 
<roll...@ghs.com<mailto:roll...@ghs.com>> 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).

This would cover all the patches with a positive code review status at
https://codereview.qt-project.org/#/q/owner:rolland%2540ghs.com+status:open,n,z

Thanks,
Best regards,

--
--
Rolland Dudemaine   tel direct:+33 143 143 
702<tel:%2B33%20143%20143%20702>
Green Hills Software   tel:+33 143 143 
700<tel:%2B33%20143%20143%20700>
4 rue de la Pierre Levee
mailto:roll...@ghs.com<mailto:roll...@ghs.com>
75011 Paris   fax: +33 143 143 
707<tel:%2B33%20143%20143%20707>
France web: http://www.ghs.com
--

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



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

Re: [Development] INTEGRITY changes for 5.7

[Liang Qi]

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 never got merged (partially because of the CI woes).
>
> This would cover all the patches with a positive code review status at
>
> https://codereview.qt-project.org/#/q/owner:rolland%2540ghs.com+status:open,n,z
>
> Thanks,
> Best regards,
>
> --
> --
> Rolland Dudemaine   tel direct:+33 143 143 702
> Green Hills Software   tel:+33 143 143 700
> 4 rue de la Pierre Leveemailto:roll...@ghs.com
> 75011 Paris   fax: +33 143 143 707
> France web: http://www.ghs.com
> --
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



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

[Development] INTEGRITY changes for 5.7

[Rolland Dudemaine]

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://codereview.qt-project.org/#/q/owner:rolland%2540ghs.com+status:open,n,z

Thanks,
Best regards,

-- 
--
Rolland Dudemaine   tel direct:+33 143 143 702
Green Hills Software   tel:+33 143 143 700
4 rue de la Pierre Leveemailto:roll...@ghs.com
75011 Paris   fax: +33 143 143 707
France web: http://www.ghs.com
--

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