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

Tue Feb 28 23:14:22 PST 2023

mstorsjo added inline comments.

================
Comment at: libcxx/docs/index.rst:121
+FreeBSD 10+     i386, x86_64, arm         ???-???
+Linux           i386, x86_64, arm, arm64  glibc-2.24+
+Windows         i386, x86_64              MSVCRT-???, MinGW???   Both MSVC and MinGW style environments
----------------
philnik wrote:
> thesamesam wrote:
> > philnik wrote:
> > > MaskRay wrote:
> > > > philnik wrote:
> > > > > This seems to be the oldest glibc version referenced in libc++.
> > > > CC @dalias @q66 @thesamesam about the supported musl versions.
> > > We don't have any bots testing musl + libc++, so I wouldn't consider musl to be supported currently. I think it might actually be broken in trunk. Maybe someone can provide a bot to test this configuration?
> > Does unsupported here mean "we expect help to fix things" or "we'll reject patches" (like we discussed in previous encounters)?
> > 
> > I think trunk works fine last time I checked.
> > 
> > I'm just not sure what the purpose of this change is with regard to libc. I don't expect the libc++ team to rush to fix musl bugs, just accept patches if we provide them.
> > 
> > I'd like to provide a buildbot but I'm not sure which hardware we could do it on right now.
> IMO it should definitely be "we'll reject patches", since that's the stance we have on any platforms, which a different libc effectively is. I guess I'll have a discussion with Louis about this at some point.
> As I'm sure I said before, the problem is that we don't know whether the code actually works and we have no way to check. This in turn means that we either don't touch the code, or we break people and then get to know about it a year later. Neither of which is healthy for a project. Another problem is that we don't know whether anybody is still interested in a platform, which means we might drag code around that nobody actually cares about (we removed a lot of that since switching to a stricter compiler and platform support policy).
> 
> If you want to provide a builkite bot we're happy to help with setting things up.
I wholeheartedly disagree that the policy should be "we'll reject patches" for anything outside of this list. There should clearly be more nuance than that to it.

For example - currently the CI covers some OSes on some architectures. For Linux, this is 4 specific architectures right now. We clearly shouldn't go ahead and add an `#if defined(__linux__) && !(defined(__i386__) || defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)) #error Unsupported configuration, not allowed to use libc++ there!`. I'm sure lots of Linux distros regularly build and use libc++ on other architectures than that. Do we guarantee that it works? No. Does it work in practice? Most probably.

E.g. for Windows on ARM64, I do build latest libc++ nightly, and run some amounts of tests with it (actual usage tests, not the libc++ testsuite itself - but I do test that one occasionally too), so it's not entirely broken. And if that gets broken, I'll let you know within 24h. It's not worthwhile to add an `#error unsupported` for such configurations, I hope you agree?

I totally agree that it's problematic to maintain the code when we don't know if it works or not, and if such code gets in the way for refactorings without a reasonable way forward, removing it might be the only option.

I get that there's a difference between untested variants of support for otherwise supported OSes already in the tree, and adding new code for entirely different OSes. But if that code mainly provides a different OS/libc specific handling of something that is already customized for all targets, I don't see a big issue with it.

There's a whole range of potential configurations inbetween, with various level of support. For new configurations, maybe aspiring to reach a level where it's included here with CI coverage in the future, it's hard to get there if any patches whatsoever are rejected unless the CI setup is there to begin with.

I.e., don't let perfect be the enemy of good. If it can provide value to users without causing maintainance harm, I don't think it needs to be rejected out of principle. If it causes maintainance issues, it should of course be reconsidered.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140343