[lldb-dev] Managing Clang and LLVM dependencies systematically

[jingham at apple.com]

I think Sean & Adrian are working on this.  Sean's out today, but I'll ask him tomorrow.

Jim

> On Nov 19, 2014, at 3:00 PM, Zachary Turner <zturner at google.com> wrote:
> 
> Reid mentioned watching the bots we already have.  Is there any way to get a Mac bot on there?  Do you guys already have one that I'm not aware of that maybe just needs to be hooked up?
> 
> On Wed Nov 19 2014 at 2:58:48 PM <jingham at apple.com> wrote:
> 
> > On Nov 19, 2014, at 1:12 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?
> 
> +1
> 
> Jim
> 
> >
> > 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
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev