[llvm-dev] Upcoming change with how libc++, libc++abi and libunwind are being built

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 20 10:02:58 PDT 2021

On Wed, Oct 20, 2021 at 9:56 AM Louis Dionne <ldionne.2 at gmail.com> wrote:

> On Tue, Oct 19, 2021 at 1:39 PM Mehdi AMINI <joker.eph at gmail.com> wrote:
>> On Tue, Oct 19, 2021 at 9:37 AM Louis Dionne via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>> On Tue, Oct 19, 2021 at 12:45 AM Michael Kruse <llvmdev at meinersbur.de>
>>> wrote:
>>>> Am Mo., 18. Okt. 2021 um 15:19 Uhr schrieb Louis Dionne <
>>>> ldionne.2 at gmail.com>:
>>>> > Nowadays, we handle all libc++'s own build bots through BuildKite at
>>>> https://buildkite.com/llvm-project/libcxx-ci.
>>>> I didn't know. Good that there is systematic testing, but I am a bit
>>>> concerned about the fracturing of the CI infrastructure (Buildbot,
>>>> Green dragon, GitHub actions, Buildkite, ...)
>>> For libc++/libc++abi/libunwind, it's actually quite simple. There's
>>> exactly one place to look, and it's BuildKite. And it runs systematically
>>> on all changes.
>> Did you find a solution for having blamelist and blame emails on
>> BuildKite?
> No, but I haven't tried. My experience so far has been that I've never had
> the need for a blamelist. Since we test everything pre-commit, you always
> know when one of your patch fails because you see it before it's been
> committed, in Phabricator. Actual breakage on main is incredibly rare
> nowadays and it pretty much only happens when someone (usually myself) is
> too keen on checking something in before CI is finished (oops!). There's
> never a lot of suspicious commits on main since the last build, so this
> isn't a problem we've encountered.
> I guess your experience can vary based on the commit traffic to the
> project and how diligent people are at testing everything pre-commit, of
> course.

There are other aspects:
- as the commit traffic increases, you can't necessarily test everything in
sequence (Rust does, but their maintainers also have to manually bundle
pull-request together: they are limited to ~7 merges per day), so
concurrent merges can interact with each other and break master.
- as the matrix of configurations increase, it does not seems possible to
just test everything (HW: PPC, SystemZ, X86, Arm, Arm64, Risc  *TIMES* the
OSes Mac, Windows, Linux, FreeBSD *TIMES* the host compilers gcc 5/6/7/...,
clang, MSVC, ... *TIMES* sanitizers build), plus some things like the
multi-stages bootstrap and such.

So in practice yeah I believe blamelist and notification are a must for
LLVM and the monorepo, libc++ may be "too small" to be representative of
the scale there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211020/50322e0e/attachment.html>

More information about the llvm-dev mailing list