Add C++20 support for configure.cxx_standard

[ryandesign (Ryan Carsten Schmidt)]

See the py-cipheycore port.

[jmroot (Joshua Root)]

• ​https://clang.llvm.org/cxx_status.html#cxx20
• ​https://gcc.gnu.org/projects/cxx-status.html#cxx20

[cjones051073 (Chris Jones)]

See ​https://github.com/macports/macports-base/pull/283

Also note a couple ports are now requesting this standard

Oberon ~/Projects/MacPorts/ports > git grep cxx_standard | grep 2020
science/seqan3/Portfile:compiler.cxx_standard   2020
sysutils/vtm/Portfile:compiler.cxx_standard   2020

Currently requesting c++20 will be effectively falling back to doing what requesting 2017 does, which definitely includes compilers that do not support the 2020 standard.

[harens (Haren S)]

Fixed by Chris in [f23dca5afb4bf4a01accb861d9095f9383e41930/macports-base]

[mascguy (Christopher Nielsen)]

I think the few ports requesting Cxx20, presently blacklist Xcode Clang across-the-board. We'll want to fix those. (I can take care of those.)

[mascguy (Christopher Nielsen)]

Replying to mascguy:

I think the few ports requesting Cxx20, presently blacklist Xcode Clang across-the-board. We'll want to fix those. (I can take care of those.)

Per discussion with @cjones earlier today, a new release of MacPorts base is still needed. And the aforementioned cleanup is dependent on that.

Reopening until that has been taken care of, as our C++20 support isn't complete yet.

[jmroot (Joshua Root)]

This is a base ticket; open another one for ports that need changes.

[mascguy (Christopher Nielsen)]

Replying to jmroot:

This is a base ticket; open another one for ports that need changes.

Sure, fair enough. But I reopened this specifically because base hasn't had a new release with this functionality yet. Or at least, that was my understanding.

Is my understanding correct...?

[ryandesign (Ryan Carsten Schmidt)]

Yes, there has not yet been a release containing this improvement.

I don't believe it's MacPorts policy to keep a base ticket open until there has been a MacPorts release; as far as I know we close a ticket when we commit the code that satisfies resolving the ticket.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

Yes, there has not yet been a release containing this improvement.

I don't believe it's MacPorts policy to keep a base ticket open until there has been a MacPorts release; as far as I know we close a ticket when we commit the code that satisfies resolving the ticket.

If that's our policy, that's fine. But the downside of closing a ticket before it's been released, is that it's less likely for folks to find the issue when searching for it.

[Sam <30577766+Samasaur1@…>]

In 26b753cfa2679974c2ce9e2593515613be1b42b6/macports-ports (master):

Use PortGroups to avoid hardcoding values

This allows the use of any compiler that supports the C++20 standard.
Since MacPorts does not yet know what that standard is
(see #62677), I am also blacklisting
versions of Clang and GCC that do not work to build btop.

Note that this currently fails with GCC on my machine, since it attempts
to use the system libc++, which does not support the features of C++20
that btop requires.