Re: [Development] Qt Release and bugfix

[Thiago Macieira]

On Wednesday, 18 September 2019 11:49:23 PDT Christian Ehrlicher wrote:
> >> The bug is marked as resolved in Qt 5.12.4, but, is it merged in Qt
> >> 5.13/5.13.1?> 
> > Yes, fix was initially integrated in '5.12' and '5.12' is merged to '5.13'
> > from where it is then went in Qt 5.13.0 and future releases
> If you want to see where the patch is currently available just click on
> the review ( https://codereview.qt-project.org/c/qt/qtbase/+/259142 )
> and then on 'Included In'.

There's a bot now that automatically sets the version that the patch landed in 
in the JIRA task.

-- 
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] Qt Release and bugfix

[Christian Ehrlicher]

Am 18.09.2019 um 14:13 schrieb Jani Heikkinen:

-Original Message-
From: Development  On Behalf Of
Fausto Papandrea
Sent: keskiviikko 18. syyskuuta 2019 13.39
To: development@qt-project.org
Subject: [Development] Qt Release and bugfix

Good morning,

I have to update my Qt version because of this bug
https://bugreports.qt.io/browse/QTBUG-74076.

The bug is marked as resolved in Qt 5.12.4, but, is it merged in Qt 5.13/5.13.1?

Yes, fix was initially integrated in '5.12' and '5.12' is merged to '5.13' from 
where it is then went in Qt 5.13.0 and future releases

If you want to see where the patch is currently available just click on
the review ( https://codereview.qt-project.org/c/qt/qtbase/+/259142 )
and then on 'Included In'.

HTH,
Christian
___
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

[Development] Created graphical object was not placed in the graphics scene

[Tomas Konir]

Hi,

I tried code like below and getting message:
QQmlComponent: Created graphical object was not placed in the graphics
scene.

import QtQuick 2.13
import QtQuick.Controls 2.12
import QtQuick.Window 2.13

Window {
visible: true
width: 640
height: 480
Button {
anchors.centerIn: parent
text: "show"
onClicked: menu.popup()
}
Menu {
id: menu
}
Component {
id: component
MenuItem {
}
}
Component.onCompleted: {
var item = component.createObject(menu)
item.text = "test menu"
menu.addItem(item)
}
}

Am i doing something wrong? Or it is a BUG in Qt ?

Regards

Tom

-- 
Tomas Konir
Czech Republic
___
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

[Development] Qt Contributors' Summit 2019 - Registration open!

[Kai Köhne]

Hi,

Registration to the Qt Contributors Summit 2019 (Nov 19-21th) is now open!

https://www.surveymonkey.com/r/RNN7NXP

The event is open to anyone who has contributed to Qt. It is free of charge, 
but requires registration so that we can do some planning. There's also a 
maximum amount of people we can accommodate, so it's best to register as soon 
as you have made plans!

You can find more about the event at

  https://wiki.qt.io/Qt_Contributors_Summit_2019

We'll continue to update the wiki, especially the program page: 
https://wiki.qt.io/Qt_Contributors_Summit_2019_Program

Regards

Kai

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt Release and bugfix

[Jani Heikkinen]

> -Original Message-
> From: Development  On Behalf Of
> Fausto Papandrea
> Sent: keskiviikko 18. syyskuuta 2019 13.39
> To: development@qt-project.org
> Subject: [Development] Qt Release and bugfix
> 
> Good morning,
> 
> I have to update my Qt version because of this bug
> https://bugreports.qt.io/browse/QTBUG-74076.
> 
> The bug is marked as resolved in Qt 5.12.4, but, is it merged in Qt 
> 5.13/5.13.1?

Yes, fix was initially integrated in '5.12' and '5.12' is merged to '5.13' from 
where it is then went in Qt 5.13.0 and future releases

> 
> What's the strategy of the release and bugfix merging?

At that tíme '5.12' was the stable one and by default all fixes should be 
integrated in that branch. 

So merges went 5.12 -> 5.13 -> dev. And in case of release branch exists those 
are merged back to feature branch (meaning 5.12.x -> 5.12 and 5.13.x -> 5.13).

At the beginning of September '5.12' was moved to cherry-pick mode meaning no 
more merges from 5.12 -> 5.13. So from now on merges are:

5.13 -> 5.14 -> 5.15 -> dev + possible merges from release branch to feature 
branch (5.12.x -> 5.12 and so on)

br,
Jani
___
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] Qt Release and bugfix

[Fausto Papandrea]

Good morning,

I have to update my Qt version because of this bug 
https://bugreports.qt.io/browse/QTBUG-74076.


The bug is marked as resolved in Qt 5.12.4, but, is it merged in Qt 
5.13/5.13.1?


What's the strategy of the release and bugfix merging?

Thank you.

___
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] Merging wip/qt6 to dev

[Simon Hausmann]

Hi,

Okay, qt5's dev branch has now a slightly reduced configuration set and qtbase 
wip/qt6 was merged to dev. So qtbase dev now has QT_VERSION set to 6.0.0.

>From this point on, I'll try to drive the merges and updates of the remaining 
>modules using the new module pinning.

Simon

From: Lars Knoll 
Sent: Tuesday, September 17, 2019 10:03
To: Simon Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Merging wip/qt6 to dev

I’d say yes, let’s merge those into dev as well. Those are all platforms we 
don’t want to support in Qt 6.0. (tvOS, watchOS and Integrity might come back 
at some point).

Cheers,
Lars

On 17 Sep 2019, at 09:56, Simon Hausmann 
mailto:simon.hausm...@qt.io>> wrote:


I'm leaning towards the same.

Regarding the overall merge, there is one other change that needs to happen 
before we can have a chance at building qtbase:

In the wip/qt6 branch in commit 5677a43a25a9dc1a3151e6b28cbf9fe015a1aff4 in 
qt5.git, various platforms and configurations were removed from the CI:

* MSVC2015
* Some MSVC 2017 configurations
* macOS 10.12, macOS 10.13
* TvOS, WatchOS
* Integrity


What shall we do about this? Merge the reduction also into dev?


Simon

From: Lars Knoll mailto:lars.kn...@qt.io>>
Sent: Tuesday, September 17, 2019 9:15
To: Simon Hausmann mailto:simon.hausm...@qt.io>>
Cc: Qt development mailing list 
mailto:development@qt-project.org>>
Subject: Re: [Development] Merging wip/qt6 to dev

Hi,

Great to get the wip/qt6 branches merged back into dev. I’d simply try to take 
the dependencies.yaml into use at the same time instead of having to work 
around the CI.

Cheers,
Lars

On 17 Sep 2019, at 09:05, Simon Hausmann 
mailto:simon.hausm...@qt.io>> wrote:

Hi,

Now that the Qt 5.15 branches exist and dev is intended to become Qt 6.0.0, the 
time has come to begin merging the wip/qt6 branches into dev. A wip/qt6 branch 
has been created for pretty much all repositories in qt6.git that are active 
(essential, addon, etc.) and two types of changes have been pushed into these 
branches:

* Update .qmake.conf to bump the module version to 6.0.0.
* Compile fixes after the initial round of source incompatible changes to 
qtbase -- most about endl, hex, etc. now always being in the Qt namespace.

qtdeclarative has seen a few more changes on the Qml side regarding the module 
structure and loading. Those were coordinated with Ulf and Fabian.


So unless somebody can think of a good reason, it is time to begin merging the 
wip/qt6 branches to dev for each repository. This may require a force push due 
to the dependency on a newer qtbase and the newer qtbase by itself not making 
it through qt5. At the same time, perhaps it would make more sense to add 
dependencies.yaml files (see other email in the  Qt6 and modules thread from 
today) while we're at it.




Simon
___
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] RFC: handling of C++ feature test macros

[Lars Knoll]

> On 18 Sep 2019, at 01:37, Thiago Macieira  wrote:
> 
> On Tuesday, 17 September 2019 16:05:34 PDT Giuseppe D'Angelo via Development 
> wrote:
>> While I agree that at the moment it has virtually never happened, it
>> doesn't mean it couldn't happen in the future. Even today we have
>> compilers such as MSVC with "living on the edge" compile flags
>> (/c++latest). Our users can use those, and thus potentially trigger
>> codepaths that on their specific compiler version are implemented in a
>> pre-Standard way.
>> 
>> So, how academic (I think should I say paranoid...) do we want to be?
> 
> Marc's proposal is that we should accept that these things are rare and 
> simply 
> correct when they do happen. Since our code is tested with the currently 
> latest versions of all compilers, we're fairly sure that any such macro works 
> with the compilers that currently support the feature.
> 
> When a new compiler comes out with the feature, we may get compilation 
> errors. 
> Our users understand that we cannot test things that don't exist, so older 
> versions can fail to compile on new compilers (or produce a lot of warnings). 
> Issuing fixes is enough.

I agree. No point in doing lots of additional work preemptively. Let’s fix them 
when they occur.

Cheers,
Lars

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