On 16.02.22 16:45, Casey Bodley wrote: > On Wed, Feb 16, 2022 at 10:24 AM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: >> On Wed, Feb 16, 2022 at 7:17 AM Casey Bodley <cbodley@xxxxxxxxxx> wrote: >>> thanks Greg, >>> >>> On Tue, Feb 15, 2022 at 8:51 PM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: >>>> On Thu, Feb 10, 2022 at 8:36 AM Casey Bodley <cbodley@xxxxxxxxxx> wrote: >>>>> the R release could be a good opportunity to make the switch to c++20 >>>>> >>>>> gcc and clang both track their support for c++20 features over >>>>> compiler versions in: >>>>> https://gcc.gnu.org/projects/cxx-status.html#cxx20 >>>>> https://clang.llvm.org/cxx_status.html#cxx20 >>>>> >>>>> thanks to the dev toolset in rhel/centos, we should already have >>>>> access to compilers that support c++20. for ubuntu, focal is still on >>>>> gcc-9 which doesn't understand -std=c++20 at all, but clang-10 does >>>>> >>>>> if we're willing to switch our ubuntu builds to clang, we could start >>>>> experimenting with c++20 on master now. otherwise, we can wait for the >>>>> jammy release in april >>>> Don't forget we also need to keep building for older distros. I know >>> can we be more specific about this requirement? are you saying that >>> the R release still needs to build on ubuntu focal? or that our >>> octopus/pacific/quincy releases do? >> I was thinking we need to maintain support for Ubuntu 20.04 in our >> next release, yeah. But that may not be right; I guess we generally >> try and support the most recent LTS in our new branches. So maybe this >> is a non-issue? >> >>>> it's supposed to be possible and sometimes we've managed to >>>> cross-build, but it always seems to be hit-or-miss on any given >>>> distro/compiler version. >>> i'm not sure what you mean by cross-build here - is that about CI >>> using different distros/compilers depending on the ceph branch? >> I mean you can technically build for eg Focal in a Jammy compiler to >> get support for those new compiler features. But it's hard to >> maintain. > okay thanks, i see what you mean. i think it would be ideal if we > could drop focal packages from all of our upstream releases. but if we > can't do that yet, we could continue building earlier releases in > focal so long as we avoid backporting any changes that require c++20. > i believe that's how we handled the switches to c++11 and 17 in the > past. though if we *can* drop focal entirely, that would make it a lot > easier to adopt the new c++20 features > Building ceph on Proxmox VE, i.e., a Debian derivative here. Current stable Debian Bullseye is supported until around summer 2024, meaning that Quincy's support life time should cover that, and using gcc 10.2, so most of C++ 20 isn't an issue, but the compat table shows that some parts only got added in gcc 11 or even 12, so we'd definitively appreciate to have CI checking for Debian Bullseye (i.e., gcc 10's) C++20 ability to cope with back ported patches, Having the option to build the R release on Debian Bullseye would be great in general, but not a "hard requirement" for us if Q EOL cover us for that release. In fact, it's more probable that we won't release Q for our Bullseye based release only weeks before switching it into maintenance support mode and the Debian Bookworm release will quite probably use GCC 12, so we'd be golden for C++20 there. I'm not involved in Ubuntu nor do I know much about how it "digests" ceph releases in general, so please don't read to much into it, but if Quincy would still be supported for focal due to ensuring that backports are not relying on C++20 features, users of the focal release would have enough time to upgrade either to the next 22.04 LTS and even to the one after that, 24.04, until Quincy goes EoL in 2024 which doesn't sounds /that/ bad to me, as there's no gap for a supported Ceph version in-between the Ubuntu LTS releases. Thanks - Thomas _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
