Re: C++20 and newer C++ compiler

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux