[lldb-dev] Managing Clang and LLVM dependencies systematically
zturner at google.com
Wed Nov 19 13:19:33 PST 2014
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
> 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-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
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev