On Thursday, 27 January 2022 08:53:31 PST Tor Arne Vestbø wrote: > I don’t know what other things you’re referring to, but just to clarify, > this is not the case for macOS. We build the binary Qt packages with as > recent of an Xcode (and corresponding toolchain) as we have available in > the CI, typically the latest version.
The Xcode case has the same constraint, just a different implementation of it. We use the latest compiler and the latest SDK that Apple provides for us, but we set the minimum macOS target (and the other Apple platforms) to the minimum that we still support. That has the effect that functions that have been added to the SDK since that minimum become weak symbols, which allow us to verify whether they are present at runtime. We know Apple has done such shenanigans for the libc++ headers in the past. Maybe not for an inline-only std::span, but certainly for filesystem and other content that has out-of-line content. That's one of the reasons why we have some checks in at our configure/cmake time whether such functionality is usable, above and beyond the __cpp_lib_xxx macros getting defined. So here's my counter-proposal: We allow C++17 and C++20 Standard Library types in our ABI provided: * we update our builds, all of them, to build with C++20 by default * the use of those symbols in the ABI is NOT behind an #if __cpp_lib check The second requirement is to ensure that the oldest compilers support the symbol in question. If you make it optional, then the build will succeed but the symbol will be missing. -- 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
