[Bug 295767] The C++ feature std::from_chars (with float value) is missing

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295767

--- Comment #5 from Matthias Andree <mandree@FreeBSD.org> ---
There is no "ports" team, if you mean "portmgr", the current team also has a
track record of leaving committers of major subsystems out in the rain without
support and giving cover for obstructive behavior, so let's please separate the
technical matter from the acting people, and here goes:

I agree that there needs to be sufficient coordination between the ports system
and the base system, so that a new FreeBSD base system release does not just
break hundreds of ports, but I observe that the practical outcome is that we
are currently tying FreeBSD's  entire C++ support to the oldest base system
libc++ across all supported FreeBSD releases, which is 14.3 for now, and will
then be 14.4 or 15.0 next month - and *THAT* is the basis for ports.  Requiring
the base system to be the tip of -STABLE, or -CURRENT, doesn't work for ports.

Might be this shouldn't be fixed solely by freebsd-toolchain@ but instead by
portmgr@ or core@, and the fix COULD be that we:

1 - TBD: make the libc++ parts in the base system private, so it's only used by
the C++-based components of the base system, but not ports
2 - add a libc++ port that is up to date and can be updated independently of
the base system
3 - add a FLAVOR to all C++ library ports that expose C++ linkage interfaces
(as opposed to C linkage) that relies on the "ports libc++",

These items are probably only for the ports@ matter:

4 - add a FLAVOR similar to #2 but that instead exposes the current "default
ports GCC version"
5 - maybe add other FLAVOR variants (Tier 2 as in "no promises" or "no
obligation for contributors") for other C++ ABIs.

Note that the C++ approach is very different to the one seen by Go or Rust -
the latter ones aren't tied to base system versions, and can move much quicker.

-- 
You are receiving this mail because:
You are the assignee for the bug.