Simon.Hausmann at qt.io
Wed Sep 18 13:52:33 CEST 2019
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:
> Can someone expand on the plan forward for the supported INTEGRITY
> 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
More information about the Development