If I'm working on something like stepping or process control or whatever, I don't really need to know whether there's some change in llvm land, I'm not touching those code paths. There is quite a lot of lldb that doesn't go through the expression evaluator, or only requires that you have some working version, not the most recent one. So I go for days quite happily not updating my llvm/clang checkout. I only bother about that if I'm working on the type system or expression evaluator. Moreover, I don't really want to know that somebody broke something in clang/llvm and then fixed it a couple of hours later. That is just noise that is not helpful to the work I am doing.
So I tend to not update my clang/llvm checkouts till something - usually some interface change that somebody else checks into lldb - forces me to. Jim > On Jul 29, 2014, at 4:37 PM, Chandler Carruth <chandl...@google.com> wrote: > > > On Tue, Jul 29, 2014 at 4:32 PM, Todd Fiala <tfi...@google.com> wrote: > I generally sync llvm/clang in the AM, locked, and work with that throughout > the day. If I kept up with TOT on all, all day long, I'm pretty sure my work > machine, big as it is, would be building all day long ;-) > > This certainly isn't true for LLVM, Clang, and LLD themselves. With > cmake+ninja, it is not at all burdensome. I'm on the extreme end and will > routinely update over 40 or 50 times a day. > > The only time this has bitten me is when something LLDB depends on changes. > Then I fix that or synch to the fix requirement that somebody else made. > > Are you suggesting something different? > > I'm suggesting a) *always* sync in or order to "fix" so that it is easy to > make cross-cutting changes without people wasting time inventing a compatible > way of doing it, and b) to including syncing every repo as the first step of > any "i have tests failing in a clean build?" sanity check. Certainly, that > seems more productive than asking people to stop committing. > > In LLVM land we have build bots that make sure that if anyone breaks tests, > the patch is reverted. Really, really fast. As a consequence, there is never > a need to "stop committing". I think that's a much healthier plan especially > with increasingly distributed contributors to LLDB. > > Just my 2 cents though. As I said, I'm just lurking here. =D > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
