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 [email protected] https://lists.qt-project.org/listinfo/development
