[lldb-dev] Managing Clang and LLVM dependencies systematically

[Zachary Turner]

I think one of the use cases they were trying to solve was being able to
bisect and find which change caused a particular break.  It might be worth
mentioning https://github.com/chapuni/llvm-project, which is a git repo
which is exactly for this purpose, and AFAIK is automatically maintained to
ToT and has no limitations.

On Wed Nov 19 2014 at 1:12:02 PM Reid Kleckner <rnk at google.com> wrote:

> I don't think Chromium's dependency rolling model is a good fit for the
> way that LLDB should consume Clang/LLVM.
>
> I would say that Chromium is to Blink as LLDB is to Clang. Both are run
> under the same parent umbrella project. However, I've been lead to
> understand that Blink rolls are a huge pain, and Chromium is actively
> moving away from this model by attempting to merge the repositories.
>
> I'm not proposing merging LLDB and Clang repos, but I would say that we
> should consider them part of the same project. If Clang changes break LLDB,
> then there is a burden on the Clang developer to to fix LLDB promptly or
> find someone with more LLDB knowledge if the fix isn't trivial. This is the
> relationship that Clang already has to LLVM. It's OK for LLVM to break
> Clang, and it should be OK for Clang to break LLDB, so long as it's fixed
> promptly. If the fix isn't prompt, it's OK to start reverting to get back
> to green.
>
> In short, what I really think we need is:
> - More stable LLDB tests with more signal and less noise
> - More visibility into LLDB build and test failures for Clang and LLVM
> developers
>
> Rather than spending time managing blessed revisions, I would rather spend
> resources watching the bots we already have (
> http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang,
> http://lab.llvm.org:8011/builders/lldb-x86_64-freebsd) and pinging
> developers on email and IRC to fix regressions. In other words, take a
> harder stance on breakage.
>
> Does that seem reasonable?
>
> On Wed, Nov 19, 2014 at 11:09 AM, Vince Harron <vharron at google.com> wrote:
>
>> We completely agree that there should be a continuous build with
>> top-of-everything.
>>
>> We're looking to *add* a continuous lldb build with the curated versions
>> of llvm/clang.  I think this will help lldb developers with the signal to
>> noise ratio.  (Separating their breaks from clang/llvm breaks)  I can
>> probably get some CPU time for this new build.
>>
>> Chromium does a similar thing with their multitude of open source
>> dependencies.  Siva was explaining to me that there is a engineer
>> "gardener" that updates the working versions file daily (we could do
>> weekly) by looking for successful "top-of-everything" builds.  The
>> "gardener" responsibility is handed off in rotation.
>>
>> Why don't we do this as a trial.  We will setup the hardware (linux at
>> least) and take responsibility for gardening.  We would like our build
>> slave to be triggered by the llvm buildbot master.
>>
>> If there is value in this to the community, we'll expand the gardening
>> responsibilities.  We can also update the public lldb build instructions to
>> use the curated build script.
>>
>> Thanks,
>>
>> Vince
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141119/3533cb93/attachment.html>