On Wed, Aug 10, 2022 at 2:11 PM Casey Bodley <cbodley@xxxxxxxxxx> wrote: > > On Wed, Aug 10, 2022 at 8:35 AM kefu chai <tchaikov@xxxxxxxxx> wrote: > > > > hi folks, > > > > as you might have already noticed, we've made the switch to C++20. see > > Casey's mail sent to this mailing list a couple days ago. > > > > another thing you need to pay attention to is, we now need to use at > > least gcc-11 or clang-12 for compiling the tree. > > > > if your working flows depend on the stock C++ compiler in your distro, > > you might need to check the version to make sure that its C++20 > > support. see also > > https://en.cppreference.com/w/cpp/compiler_support#cpp20 . for > > instance, if you are using ubuntu focal, you could use the ppa repo at > > https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test or > > prebuilt clang-12 or up at https://apt.llvm.org. if you are using > > centos/RHEL 8, you might want to use gcc-toolset-11 or gcc-toolset-12 > > or llvm-toolset-12 . > > > > apparently, we are not using all the C++20 features, but we are > > starting exploring some of them. as some of us have noticed, we have > > started using https://wg21.link/P1185R2 in the main branch. because we > > are now using both gcc-11 and clang-12 in our CI/CD workflows, we can > > assure you that these two compilers should be able to compile the main > > branch. > > > > i apologise for any inconvenience caused. > > > > cheers, > > > > -- > > Regards > > Kefu Chai > > _______________________________________________ > > Dev mailing list -- dev@xxxxxxx > > To unsubscribe send an email to dev-leave@xxxxxxx > > > > thanks Kefu, > > there was some good discussion on the topic in today's ceph leadership > call, and i wanted to share my thoughts here in more detail > > # c++20 features and compiler versions > > compiler support for c++20 features are tracked by gcc and clang: > https://gcc.gnu.org/projects/cxx-status.html#cxx20 > https://clang.llvm.org/cxx_status.html#cxx20 > > as you can see, feature support is spotty and we still don't have > *full* support in the latest compiler versions. this makes it > difficult for the ceph project to draw a line > > Kefu did a lot of testing and settled on gcc11 and clang12 as the > minimum compiler versions, so those are the versions we're using in > ceph's CI. these may change in the future, but the vague answer to > questions about whether we can use a particular c++20 feature is 'yes > if it builds in CI'. there may be some cases where a feature builds > with gcc but not with clang, but this is nothing new - we'll just have > to continue dealing with those as they come up > > # distros and default compiler versions > > ceph has been supporting centos 8 and ubuntu 20.04 for a long time, > and their default compiler versions are really old by now. as Ken just > announced in 'linux distro requirements for reef', the reef release > will target centos stream 9 and ubuntu 22.04, so development on the > 'main' branch should switch asap. Kefu and David have been working > hard to add these distros to our CI, and it sounds like ubuntu 22.04 > is just about ready. if you're interested in helping with this, i'd > encourage you to reach out in #sepia irc > > # ceph's cmake > > https://github.com/ceph/ceph/pull/45133 merged last week, which raised > the CMAKE_CXX_STANDARD from 17 to 20. unfortunately, because c++20 > support is so fuzzy, cmake doesn't actually enforce a minimum compiler > version. as a result, developers using their default compilers started > seeing build failures after the merge of > https://github.com/ceph/ceph/pull/47427 which introduced the first use > of the c++20 spaceship operator > > i know that it's frustrating to see your development builds start > failing because of changes like this, without any clues to resolve > them. i'd like to find a way to turn these compilation failures into > an obvious cmake error message that offers additional guidance > > cmake does have some granular control over language feature support > with https://cmake.org/cmake/help/latest/command/target_compile_features.html. > hypothetically, that would allow us to do something like > 'target_compile_features(ceph-common PUBLIC cxx_spaceship)' to require > a compiler version that supported c++20's spaceship operator. however, > https://cmake.org/cmake/help/latest/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html > doesn't list any features past c++14. so instead i'm proposing in > https://github.com/ceph/ceph/pull/47543 that we add an explicit check > for compiler versions, with error messages that make it clear exactly > what compiler version is required > > is there more we should do to ease this transition? let me know what you think Laura pointed out https://tracker.ceph.com/issues/57073, which was a regression in install-deps.sh on centos from https://github.com/ceph/ceph/pull/45133. i've pushed https://github.com/ceph/ceph/pull/47548 to fix that and its warning message when the compiler version is out of date _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx