ecmwf
c++20 - first draft
Description
Contributor Declaration
By opening this pull request, I affirm the following:
- All authors agree to the Contributor License Agreement.
- The code follows the project's coding standards.
- I have performed self-review and added comments where needed.
- I have added or updated tests to verify that my changes are effective and functional.
- I have run all existing tests and confirmed they pass.
Because header files of eckit require C++20, then downstream packages will fail unless they all adapt the required C++ standard.
Instead, one can add the compile features as PUBLIC to a target, as I did e.g. with atlas for C++17: (https://github.com/ecmwf/atlas/blob/develop/src/atlas/CMakeLists.txt#L1058C1-L1058C51)
target_compile_features( atlas PUBLIC cxx_std_17 )
Probably the core eckit library could set this, and then the downstream packages will inherit.
How likely is it that we move the whole stack to C++20? When it is possible to do for eckit, it must be possible for the whole stack?
How likely is it that we move the whole stack to C++20? When it is possible to do for eckit, it must be possible for the whole stack?
If eckit requires c++20 then naturally everything depending on eckit (so nearly every of our C++ packages) will have c++20 enabled.
I could really make use of concepts, constexpr std::strings, designated initializers, ranges & views (e.g. replacing the Tokenizer).
If eckit requires c++20 then naturally everything depending on eckit (so nearly every of our C++ packages) will have c++20 enabled.
No only would most C++ packages would need to move to C++20, but also some of our infrastructure (namely CI runners) would have to evolve e.g. rocky 8.6 runners are provisioned with GCC 8.5.0 which provides only minimal C++20 support via option --std=c++2a. GCC 8.5.0 is also the system compiler, and used to build packages to be installed on the HPC.
@tlmquintino , @simondsmart , @Ozaq , relating to the entire software stack (but starting with eckit), do we have a proposed time line, (or could we have one if not), on when we drop support for certain compilers / versions? Could this be made available publicly on a webpage? Similarly such page should state which compilers/version we currently guarantee due to CI-testing, and then compilers which we aim to support to best efforts but cannot always test, either because we didn't yet do, or because we don't have access (e.g. we should aim to support HPE/Cray, AMD/AOCC, NEC, NAG (Fortran), ...)
We should also involve such timeline for the version of CMake, and standard version of C and C++.
Such timeline should help us to deprecate CI runners and upgrade to new ones. Similar to how Github's own runners get deprecated over time.