[llvm-dev] [libcxx-dev] Compiler support in libc++

[Louis Dionne via llvm-dev]

Sorry for the late reply, I'm on vacation right now and until the end of
March. See my answers below.

On Mon, Mar 8, 2021 at 11:37 AM James Y Knight <jyknight at google.com> wrote:

> "Users" are just going to use a toolchain distribution put together by
> someone else, right?
>

Yes, that would be my expectation too. I guess that depends how you define
users.


> I'd expect the person putting together such a toolchain distribution to
> download a release of llvm, and build all of the components from that same
> revision. It's historically been annoying to ensure that you actually build
> the runtime libraries using the just-built clang, when you're building a
> set of llvm+clang+compiler-rt+libcxxabi+libcxx all together, instead of
> whatever compiler you had lying around...but once the documentation and
> process is updated to make the right thing happen in the "obvious" path,
> ISTM that solves 99% of the problem here.
>

I agree, I think this solves 99% of problems.


>
> For *developers of *libc++ who are making changes against devhead, they
> may want to avoid rebuilding clang every time they want to test a new
> revision of libc++. For that, the "last stable" promise seems useful. But
> that seems like it shouldn't really affect users?
>
> The question is whether there's circumstances in which someone who is
> putting together a toolchain distribution needs to upgrade to a newer
> version of libc++, yet remain on an older release of clang (...but only up
> to 1 year old). If that's what folks are saying is necessary: maybe someone
> can help explain why? It doesn't seem like it should be needed, to me.
>

This is useful if you ship libc++ as part of a different product than the
product you ship Clang in, yet both need to interoperate. For example, we
do this on Apple platforms by means of shipping Clang in Xcode, but
shipping libc++ as part of the operating system and corresponding SDK. In
this case, the "last stable release" guarantee means that everything will
work as long as Clang keeps getting updated at a reasonable rate.


>
> On Mon, Mar 8, 2021 at 2:10 PM Roman Lebedev via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
>> On Mon, Mar 8, 2021 at 9:59 PM Reid Kleckner via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> >
>> > I think it's reasonable to raise the compiler version floor for libc++,
>> but I think I would like to see a more relaxed policy with respect to
>> clang. Maybe the last two releases of clang, so that a user of ToT libc++
>> with stable clang doesn't have to rush to upgrade clang as soon as it is
>> released. If you support the last two releases, the user always has six
>> months of lead time before updating, and libc++ never supports a compiler
>> older than a year.
>>
>
Hmm, yes, I think that would make sense. This would indeed give more leeway
to folks testing ToT libc++ with a released Clang, so that they wouldn't
need to update the Clang on their CI fleet the very second a new Clang gets
released (if they don't, the next libc++ commit could technically break
them). I think that makes sense - at least we can start with that and see
if we want to make it more stringent in the future.

I'll be creating a Phabricator review to enshrine this updated policy when
I come back from vacation, and it will start being enforced at the next
release.

Louis



> >
>> > I'll also point out that, I see a lot of support on this thread, but I
>> see a lot of developer representation, and not much user representation. I
>> have no idea how to effectively survey users of libc++, though.
>> +1.
>> From user POV, supporting only the last two stable clang releases
>> is *the smallest reasonable guarantee*.
>>
>>
>> Roman
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210316/d687455d/attachment.html>