[libcxx-commits] [PATCH] D140343: [libc++] Update supported system versions

[Louis Dionne via Phabricator via libcxx-commits]

ldionne accepted this revision.
ldionne added a comment.
This revision is now accepted and ready to land.

LGTM with the wording adjustment. This will also need to be rebased, I think.



================
Comment at: libcxx/docs/index.rst:121
+FreeBSD 12+     i386, x86_64, arm
+Linux           i386, x86_64, arm, arm64  Only glibc-2.24 and later and no other libc is supported
 Windows         i386, x86_64              Both MSVC and MinGW style environments
----------------
Our current policy for supporting other OSes/libcs/configurations is as @philnik stated. It doesn't mean that we'll go out of our way to break unsupported configurations, but it does mean that:

1. We won't let any such configuration get in the way of improvements, refactorings, reorganizations, deprecations, removals.
2. We won't accept any non-trivial or widespread changes for that platform.
3. We won't list it as supported here.

We're not against unofficial ports, in fact I even have several downstream ports that would be considered "unsupported" by the definition above. This is fine. All I am saying is that it's not reasonable to put the burden of maintenance on the upstream project. If people have small patches that e.g. add an architecture to an existing `#if defined(FOO) || defined(BAR) || ...`, I don't think you'll be met with too much resistance. However, I'm deliberately not giving any guarantees here so that we can look at it on a case by case basis and make the best decision for the project every time.

To please everyone, I think let's just be a bit hand-wavy in the documentation w.r.t. what we mean by "officially supported". This is the status quo and it works reasonably well (if not someone please raise that).

To address @philnik 's concern about `__locale` specifically, I agree it's a freakin' mess over there. I think it should be possible to refactor in a way that we hide much of the platform-specific stuff away of our main implementation, untying our hands to touch `__locale`. In the current state of things, honestly I don't think any frequent contributor feels confident modifying our localization code, and that's a problem (not only theoretical -- I had to do some porting work recently and it was a real hindrance). If we can't refactor that effectively, then I would go for something more aggressive and prune configurations that are not supported officially, basically changing above back to `Only glibc-2.24 and later and no other libc is supported`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140343/new/

https://reviews.llvm.org/D140343