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
