Page MenuHomeFreeBSD

src.opts.mk: Require C++20 for C++ support.
ClosedPublic

Authored by jhb on Oct 5 2022, 11:51 PM.
Tags
None
Referenced Files
F103065326: D36893.diff
Wed, Nov 20, 11:39 AM
Unknown Object (File)
Thu, Nov 7, 2:00 PM
Unknown Object (File)
Tue, Nov 5, 11:28 AM
Unknown Object (File)
Mon, Oct 21, 1:39 PM
Unknown Object (File)
Oct 14 2024, 4:34 PM
Unknown Object (File)
Oct 10 2024, 5:29 AM
Unknown Object (File)
Sep 24 2024, 6:30 AM
Unknown Object (File)
Sep 23 2024, 3:24 AM

Details

Summary

libc++ requires C++20, so mark C++ (MK_CXX) as broken if the compiler
does not support C++20.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jhb requested review of this revision.Oct 5 2022, 11:51 PM

So where does this draw the line for the upgrade path? stable/12? Stable/11? stable/13?

This is really about how old of a compiler do we want to support. Note that LLVM 14 has been merged back to stable/12 I think, so C++20 compilers are effectively required to build a full system for even stable/12. That part is already true. The question is do we allow older compilers (namely GCC 9) to build a subset of world still. One argument could be that we simply say GCC 9 is now unsupported. (I do have world building with GCC 12 now, though it requires a change to libc++ I haven't yet posted). If we decide that, that's fine, but it means I need to flip to GCC 12 as soon as I can for at least head for Jenkins. The cow is out of the barn in that case for stable branches though.

Also, I should clarify. Trying to build with clang 9 or GCC 9 just fails with an error about an invalid value passed to -std= when you get to libc++ today. This change just means that those older compilers can skip C++ bits and build the rest of the world. It is up for debate how useful that is. I don't know what the last branch we shipped with clang 9 was.

It seems I forgot about D33108. IMO I should just rebase and commit that, and we can require a C++20 compiler.

That said, I have no issue with this series being committed first.

Well, if we plan to deprecate MK_CXX then this series is just noise and that means deprecating GCC 9. I'm fine with that though.

To be clear, I don't have a problem requiring a c++20 compiler, though only clang needs it. devd certainly doesn't, for example.
And my question about where the line is drawn was more with an eye towards updating the minimal version in Makefile.inc1 than objecting to this change.
I want to know so it can be documented.
And I'm certainly not objecting in anyway to this change. My comments are more to find where the line is drawn "on the ground today", not to say we need to move it back or that we can't move it.

In D36893#837830, @imp wrote:

To be clear, I don't have a problem requiring a c++20 compiler, though only clang needs it. devd certainly doesn't, for example.
And my question about where the line is drawn was more with an eye towards updating the minimal version in Makefile.inc1 than objecting to this change.
I want to know so it can be documented.
And I'm certainly not objecting in anyway to this change. My comments are more to find where the line is drawn "on the ground today", not to say we need to move it back or that we can't move it.

It's not clang that needs it, it is libc++. You can't have any C++ without having a C++ runtime library to link against. The line as far as I know is whatever release last shipped clang 9. Digging around a bit, it seems that 12.2 shipped clang 10.0.1 (12.1 shipped clang 8), so currently you need 12.2 or newer to build any of stable/12, stable/13, or main.

This revision is now accepted and ready to land.Oct 11 2022, 8:41 PM

Well, if we plan to deprecate MK_CXX then this series is just noise and that means deprecating GCC 9. I'm fine with that though.

I think that removing the MK_CXX option and requiring a C++ compiler is required, eventually, but I'm happy to have this series go in for now and hold off on my change for a bit -- I'm less inclined to make a C++20 compiler a requirement today.

This revision was automatically updated to reflect the committed changes.

I should note that anyone using default LLVM (except for powerpc) as external toolchain would be bitten. (Not me, though.)
Default LLVM on ports is still stuck on devel/llvm90 (devel/llvm10 for powerpc only) according to Mk/bsd.default-versions.mk.
Maybe now would be time to switch default LLVM to devel/llvm10 or later (devel/llvm13, which is required by mesa?).