Re: [Development] Nominating Luca Di Sera as approver

[Topi Reiniö]

+1. Luca has already been an invaluable asset to QDoc development among other 
things.

Disclaimer; we're colleagues.

-Topi

Get Outlook for Android

From: Development  on behalf of Paul 
Wicking 
Sent: Tuesday, February 1, 2022 7:04:13 AM
To: development@qt-project.org 
Subject: [Development] Nominating Luca Di Sera as approver

Hi,

I'd like to nominate Luca Di Sera as approver in the Qt Project.

Luca joined The Qt Company as a Software Engineer six months ago. His 
contributions [0] and reviews [1] are steady and of high quality. Some of his 
contributions are in TQtC internal repositories. I particularly appreciate 
Luca's style of communication in reviews, carefully crafted commit messages, 
and his passion for solid and maintainable software architecture. I've come to 
know him as an engineer that quickly found ways to apply himself within the 
team, who is not afraid to share his views, and that contributes to moving 
discussions toward sensible outcomes.

I am convinced Luca will treat the status as Approver with the utmost respect 
in the years to come.

Disclaimer: I am Luca's line manager in TQtC and as such have a close working 
relationship with him.

//! Paul

[0] - https://codereview.qt-project.org/q/owner:luca.disera%2540qt.io
[1] - https://codereview.qt-project.org/q/reviewer:luca.disera%2540qt.io
___
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] Nominating Luca Di Sera as approver

[Paul Wicking]

Hi,

I'd like to nominate Luca Di Sera as approver in the Qt Project.

Luca joined The Qt Company as a Software Engineer six months ago. His 
contributions [0] and reviews [1] are steady and of high quality. Some of his 
contributions are in TQtC internal repositories. I particularly appreciate 
Luca's style of communication in reviews, carefully crafted commit messages, 
and his passion for solid and maintainable software architecture. I've come to 
know him as an engineer that quickly found ways to apply himself within the 
team, who is not afraid to share his views, and that contributes to moving 
discussions toward sensible outcomes.

I am convinced Luca will treat the status as Approver with the utmost respect 
in the years to come.

Disclaimer: I am Luca's line manager in TQtC and as such have a close working 
relationship with him.

//! Paul

[0] - https://codereview.qt-project.org/q/owner:luca.disera%2540qt.io
[1] - https://codereview.qt-project.org/q/reviewer:luca.disera%2540qt.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing to officially allow C++20 types in Qt 6 ABIs

[Thiago Macieira]

On Monday, 31 January 2022 10:44:07 PST Giuseppe D'Angelo via Development 
wrote:
> I was referring to the "defaulting to C++-latest". In order to know what
> *is* the "latest" you can target, you need to detect the CMake and the
> compiler versions. That means start building tables of supported
> combinations. Probably nothing too complicated, still, work to do.

> 
> That's an orthogonal decision. Bumping the minimum requirement of Qt to
> C++20 will simply reopen the same questions for C++23, won't it?

Not exactly, because of the difference between incoming and outgoing ABI.

If we allow C++2N symbols in *our* ABI, then those must always be present in a 
supported build (if you don't want support, you can do whatever you want). If 
that implies raising the minimum compiler version or minimum CMake version, 
therefore dropping support for older OS environments, then so be it. That's 
our choice.

But we can allow use of C++2N symbols in the ABI we *use*, if those were 
detected during the build. Downgrading the compiler and its C++ standard 
library is not supported neither by us nor by the compiler vendors, so we can 
be assured that this build of Qt will be run against the same version or 
newer. Those symbols will be present. They just can't be mandatory for all 
source builds.

> So, concretely, this just means: use feature macros to guard the
> relevant APIs. The C++17 project won't see the APIs as available, so it
> can't use them, and won't get no compile errors.

Correct, provided Qt was compiled with C++20.

> > I'd say no. That was my reply to Lars just now and the gist of my
> > opposition
> > to Marc's initial proposal: a C++17 build of Qt is an unsupported "send
> > patches, not bug reports" build.
> 
> Is this a "no" to the better QoI, or to the overall idea of making a
> C++17 build of Qt work with a C++-latest project?

To be clear: I don't mind saying that Qt now requires C++20 to build. That's 
our choice to make and I'll abstain from going either way.

However, I do mind the ABI. It must be the same for all supported builds of Qt 
that use the an ABI-compatible compiler & toolchain. I am opposing a change 
this.

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



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

Re: [Development] Proposing to officially allow C++20 types in Qt 6 ABIs

[Giuseppe D'Angelo via Development]

On 31/01/2022 17:36, Thiago Macieira wrote:

On Monday, 31 January 2022 05:23:45 PST Giuseppe D'Angelo via Development
wrote:

1) Does a build of Qt default to C++17 or C++-latest? Qt 5 did the
latter, Qt 6 does the former. I would be fine at restoring C++-latest,
with command line switches available to picking a specific C++ version
if so desired.


It defaults to C++17. We actually know of a few issues with C++20 with some
compilers and those need to be fixed, regardless of what we do about this
thread. And we should at a minimum test our headers with multiple versions of
the C++ standard, because that's an acceptable choice our users can make.


However, this smells of maintenance burden; what "latest" means depends
on the specific compiler version, that is, we need to start building
compiler+CMake version lists (older CMakes does not recognize the latest
C++ versions).


I don't see why that would be a problem for us. So an older CMake doesn't know
that GCC 10 has C++2b mode? Then we just test the C++2b mode in an OS that
comes with a suitably recent CMake.


I was referring to the "defaulting to C++-latest". In order to know what 
*is* the "latest" you can target, you need to detect the CMake and the 
compiler versions. That means start building tables of supported 
combinations. Probably nothing too complicated, still, work to do.




On top of that, C++17 is still the official minimum (= need CI coverage
for C++17 builds on all platforms).


Not if we decide that we must use C++20.


That's an orthogonal decision. Bumping the minimum requirement of Qt to 
C++20 will simply reopen the same questions for C++23, won't it?




3) Should a C++-latest build of Qt work for a C++17-compiled project? I
would say that this should work. If the post-C++17 features are guarded
by the right #ifdefs, would that be a problem?

The added bonus of making this work would be that we could offer
C++-latest binary builds of Qt and projects could still pick their
preferred C++ version to use.


I think it's a must, unless we say that user code must also use C++20 to work
with Qt and I don't think we're there yet.


So, concretely, this just means: use feature macros to guard the 
relevant APIs. The C++17 project won't see the APIs as available, so it 
can't use them, and won't get no compile errors.




4) Should a C++17 build of Qt work for a C++-latest project? I'd say
"yes", but what happens if the project tries to use an API that uses a
C++-latest datatype? At first approximation, the user might simply get a
link error (the function hasn't been built into Qt). Can we offer better
QoI here, and completely hide those functions from such builds of Qt?

Not sure if it's easy -- it would mean baking the "has C++ feature"
detection into the Qt build, maybe via CMake magic? But I would say that
it's worth it; link errors are completely meaningless to an end user.


I'd say no. That was my reply to Lars just now and the gist of my opposition
to Marc's initial proposal: a C++17 build of Qt is an unsupported "send
patches, not bug reports" build.


Is this a "no" to the better QoI, or to the overall idea of making a 
C++17 build of Qt work with a C++-latest project?



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

Re: [Development] Proposing to officially allow C++20 types in Qt 6 ABIs

[Thiago Macieira]

On Monday, 31 January 2022 05:23:45 PST Giuseppe D'Angelo via Development 
wrote:
> 1) Does a build of Qt default to C++17 or C++-latest? Qt 5 did the
> latter, Qt 6 does the former. I would be fine at restoring C++-latest,
> with command line switches available to picking a specific C++ version
> if so desired.

It defaults to C++17. We actually know of a few issues with C++20 with some 
compilers and those need to be fixed, regardless of what we do about this 
thread. And we should at a minimum test our headers with multiple versions of 
the C++ standard, because that's an acceptable choice our users can make.

> However, this smells of maintenance burden; what "latest" means depends
> on the specific compiler version, that is, we need to start building
> compiler+CMake version lists (older CMakes does not recognize the latest
> C++ versions).

I don't see why that would be a problem for us. So an older CMake doesn't know 
that GCC 10 has C++2b mode? Then we just test the C++2b mode in an OS that 
comes with a suitably recent CMake.

Additionally, I'd also limit the testing to a version of the compiler we've 
concluded that it supports the language correctly. We will find implementation 
bugs, shortcomings, and limitations because those things are in development.

> On top of that, C++17 is still the official minimum (= need CI coverage
> for C++17 builds on all platforms).

Not if we decide that we must use C++20.

> 2) Should a C++-latest build of Qt work on a C++-17 only toolchain? I
> would say absolutely not, we don't support toolchain downgrades.

Speaking specifically about building Qt, not building user code, I agree. For 
two reasons: first, that we reduce our own maintenance burden. Second, because 
of the issue I raised: binary compatibility.

> 3) Should a C++-latest build of Qt work for a C++17-compiled project? I
> would say that this should work. If the post-C++17 features are guarded
> by the right #ifdefs, would that be a problem?
> 
> The added bonus of making this work would be that we could offer
> C++-latest binary builds of Qt and projects could still pick their
> preferred C++ version to use.

I think it's a must, unless we say that user code must also use C++20 to work 
with Qt and I don't think we're there yet.

> 4) Should a C++17 build of Qt work for a C++-latest project? I'd say
> "yes", but what happens if the project tries to use an API that uses a
> C++-latest datatype? At first approximation, the user might simply get a
> link error (the function hasn't been built into Qt). Can we offer better
> QoI here, and completely hide those functions from such builds of Qt?
> 
> Not sure if it's easy -- it would mean baking the "has C++ feature"
> detection into the Qt build, maybe via CMake magic? But I would say that
> it's worth it; link errors are completely meaningless to an end user.

I'd say no. That was my reply to Lars just now and the gist of my opposition 
to Marc's initial proposal: a C++17 build of Qt is an unsupported "send 
patches, not bug reports" build.

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



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

Re: [Development] Proposing to officially allow C++20 types in Qt 6 ABIs

[Thiago Macieira]

On Monday, 31 January 2022 02:04:46 PST Lars Knoll wrote:
> We upgrade the default to C++20, but keep things compiling in C++17 mode. If
> we do that, we should however consider upgrading our minimum compiler
> requirements for the binaries (ie desktop and mobile platforms) to
> compilers that support C++20. In addition, we’ll need to add testing of
> C++17 builds in CI.

We don't need to do any of that. We don't to test that ABI-breaking options 
compile. Whoever uses them assumes the responsibility for any breakages and 
must have the will to submit patches to fix any issues they encounter. Don't 
report bugs.

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



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

Re: [Development] Proposing to officially allow C++20 types in Qt 6 ABIs

[Giuseppe D'Angelo via Development]

On 28/01/2022 02:07, Thiago Macieira wrote:

On Thursday, 27 January 2022 16:49:22 PST Marc Mutz wrote:

That would break projects that build their Qt themselves (embedded), and
with C++17 (because, you know, compile times increase with every std
version ).

Ok, then we make it optional to turn back the clock and compile as C++17. But
we default to C++20. This option would be as ABI-breaking as the feature
system or choosing qreal == float.


I'm not 100% sure I understood the outcome. Trying to summarize the 
thread here.


We want to use C++-latest stdlib types in our API _and_ ABI (i.e. out of 
line functions). For that, we obviously need a C++-latest build of Qt. 
Having C++-stdlib types in our ABI is a sailed ship, and so is getting 
an ABI break from changes in a given stdlib implementation (not our 
problem).



Debate points:

1) Does a build of Qt default to C++17 or C++-latest? Qt 5 did the 
latter, Qt 6 does the former. I would be fine at restoring C++-latest, 
with command line switches available to picking a specific C++ version 
if so desired.


However, this smells of maintenance burden; what "latest" means depends 
on the specific compiler version, that is, we need to start building 
compiler+CMake version lists (older CMakes does not recognize the latest 
C++ versions).


On top of that, C++17 is still the official minimum (= need CI coverage 
for C++17 builds on all platforms).



2) Should a C++-latest build of Qt work on a C++-17 only toolchain? I 
would say absolutely not, we don't support toolchain downgrades.



3) Should a C++-latest build of Qt work for a C++17-compiled project? I 
would say that this should work. If the post-C++17 features are guarded 
by the right #ifdefs, would that be a problem?


The added bonus of making this work would be that we could offer 
C++-latest binary builds of Qt and projects could still pick their 
preferred C++ version to use.



4) Should a C++17 build of Qt work for a C++-latest project? I'd say 
"yes", but what happens if the project tries to use an API that uses a 
C++-latest datatype? At first approximation, the user might simply get a 
link error (the function hasn't been built into Qt). Can we offer better 
QoI here, and completely hide those functions from such builds of Qt?


Not sure if it's easy -- it would mean baking the "has C++ feature" 
detection into the Qt build, maybe via CMake magic? But I would say that 
it's worth it; link errors are completely meaningless to an end user.



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

Re: [Development] Proposing to officially allow C++20 types in Qt 6 ABIs

[Lars Knoll]

> On 28 Jan 2022, at 02:07, Thiago Macieira  wrote:
> 
> On Thursday, 27 January 2022 16:49:22 PST Marc Mutz wrote:
>> That would break projects that build their Qt themselves (embedded), and
>> with C++17 (because, you know, compile times increase with every std
>> version ).
> 
> Ok, then we make it optional to turn back the clock and compile as C++17. But 
> we default to C++20. This option would be as ABI-breaking as the feature 
> system or choosing qreal == float. 

I’d be fine with that given that we have good enough C++20 support on the 
desktop and mobile platforms. We upgrade the default to C++20, but keep things 
compiling in C++17 mode. If we do that, we should however consider upgrading 
our minimum compiler requirements for the binaries (ie desktop and mobile 
platforms) to compilers that support C++20. In addition, we’ll need to add 
testing of C++17 builds in CI.

The last question is whether we would do that switch for 6.4 or 6.5.

Cheers,
Lars



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