[libcxx-commits] [PATCH] D81602: [libc++] Provide SEM_VALUE_MAX fallback on Solaris

[JF Bastien via Phabricator via libcxx-commits]

jfb added a comment.

In D81602#2087793 <https://reviews.llvm.org/D81602#2087793>, @ro wrote:

> In D81602#2087683 <https://reviews.llvm.org/D81602#2087683>, @ldionne wrote:
>
> >
>
>
>
>
> > Let's put it that way: as far as I can tell, this code is dead, so this patch isn't adding anything beyond technical debt. And the reason why it's dead is that there are no *libc++* build bots set up for Solaris, and no maintainer actively working on supporting that platform AFAICT.
>
> True, because right now `libc++` doesn't build even on Illumos.  As I mentioned, my patch is only the first in a series to change that.
>  I'd have posted more of them already but for the pushback I got on the first trivial one.  While working on my patch series, I already encountered more of those (like AIX and partially Windows) that caused me to spend quite some time trying to verify that my changes wouldn't negatively affect them, only to discover in the end that the code doesn't even compile.
>
> > JF made the comment he made because I recently complained to him about how the maintenance burden for libc++ is both huge and also rests on the shoulder of too few. The main reason for the burden being so large is that we try to support a high number of system configurations and sub-configurations of libc++ (like no-threads, no-stdio, etc.), and we also tend to bend backwards instead of requesting that systems conform to e.g. POSIX in a more stringent way. That's unfortunately part of a discussion that needs to happen and that is much larger than this patch, but my point is that libc++ needs to start dropping workarounds for systems that are not actively supported, not add new ones.
>
> Fully understood: keeping code around for dead systems is only creating work for everyone else and making the code harder to maintain
>  for no gain.  However, demanding systems that conform to the very latest C and POSIX.1 standards quickly restricts you to a very small set: many people tend to forget that.


Right, I didn't see bots for this platform and that's why I asked. I'm completely happy if libc++ supports a variety of platforms, IMO more is better because it prevents local-minimum solutions, but this has to be balanced with maintenance cost. Right now so many platforms have a semblance of support without actually being supported that it's a big hindrance to folks working on libc++. Committing a patch might break bots that are unmaintained, or might break configurations for which there are no bots at all (and the we get reports a few weeks after the facts). That's not an ideal situation at all.

If you're actually supporting Solaris, providing bots and fixing incoming breakages then I agree that the platform should be supported. However, it would be good to do more than just support a platform, and actually support libc++ as a whole. There's a significant number of bugs and features which aren't getting the attention they need, in large part because maintainers are busy with the large number of semi-supported platforms.

In other words, I'd much rather see ongoing commitments to the codebase, not just for a single platforms. The reality is that right now many important things are lagging because most folks support their platforms and nothing else. That's far from ideal, but I understand that it's sometimes the only option.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81602