<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>It seems to me that this would require one extra stage of bootstrap in CI for many buildbots.</div><div>For example, today I have a Linux bot with a clang-8 host compiler and libstdc++. The goal is to ensure that MLIR (but it is applicable to any project) builds with clang and libc++ at the top of the main branch. </div><div>So the setup is:</div><div>- stage1: build clang/libc++ with host clang-8/libstdc++</div><div>- stage2: build test "anything" using stage1 (`ninja check-all` in the monorepo for example, but applicable to any other external project)</div><div><br></div><div>With this proposal, the setup would be:</div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">- stage1: build just clang with host clang-8/libstdc++</span><br></div><div><div style="color:rgb(0,0,0)">- stage2: build clang/libc++ with stage1 clang and host libstdc++</div><div style="color:rgb(0,0,0)">- stage3: build test "anything" using stage2 (`ninja check-all` in the monorepo for example, but applicable to any other external project)</div></div><div><br></div><div>The only way to avoid adding a stage in the bootstrap is to keep updating the bots with a very recent host clang (I'm not convinced that increasing the cost of maintenance for CI / infra is good in general).</div><div><br></div><div>We should aim for a better balance: it is possible that clang-5 is too old (I don't know?), but there are people (like me, and possibly others) who are testing HEAD with older compiler (clang-8 here) and it does not seem broken at the moment (or the recent years), I feel there should be a strong motivation to break it.</div><div>Could we find something more intermediate here? Like a time-based support (2 years?) or something based on the latest Ubuntu release or something like that. That would at least keep the cost of upgrading bots a bit more controlled (and avoid a costly extra stage of bootstrap).</div><div><br></div><div>Thanks,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 2, 2021 at 7:10 AM Louis Dionne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Mar 1, 2021, at 15:41, Joerg Sonnenberger via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> On Mon, Mar 01, 2021 at 12:40:36PM -0500, Louis Dionne via llvm-dev wrote:<br>
>> However, for a library like libc++, things are a bit different.<br>
> <br>
> So how does this prevent the libstdc++ mess that you need to lock step<br>
> the RTL with the compiler and more importantly, get constantly screwed<br>
> over when you need to upgrade or downgrade the compiler in a complex<br>
> environment like an actual Operating System?<br>
<br>
Could you please elaborate on what issue you’re thinking about here? As someone who ships libc++ as part of an operating system and SDK (which isn’t necessarily in perfect lockstep with the compiler), I don’t see any issues. The guarantee that you can still use a ~6 months old Clang is specifically intended to allow for that use case, i.e. shipping libc++ as part of an OS instead of a toolchain.<br>
<br>
<br>
> I consider this proposal a major step backwards...<br>
<br>
To be clear, we only want to make official the level of support that we already provide in reality. As I explained in my original email, if you’ve been relying on libc++ working on much older compilers, I would suggest that you stop doing so because nobody is testing that and we don’t really support it, despite what the documentation says. So IMO this can’t be a step backwards, since we already don’t support these compilers, we just pretend that we do.<br>
<br>
Louis<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>