One of my posts didn't go through earlier.  It looks like I responded privately to Siva instead of to the list.  <div><br></div><div>My main issue is that I don't want the canonical way of getting a new developer started hacking on LLDB to veer either sideways or backwards with respect to how one gets started on LLVM.  It should either stay the same of veer towards LLVM, which means CMake and Ninja.<br><div><br></div><div>As a result, I wouldn't want this functionality to be hidden behind a script unless it were also accessible through CMake (similar to how you can use dotest.py to run the test suite manually, or you can just build the check-lldb ninja target after generating CMake).</div></div><div><br></div><div>One way to do this in CMake might be to have an LLDB_USE_LKGR_LIBS CMake variable which defaults to false.  If it's true, it runs this script to set up the build environment in whatever way is necessary to get these revisions, and then using ninja works the way it always does, just build the lldb target and it will automatically use the LKGR targets.</div><br><div class="gmail_quote">On Wed Nov 19 2014 at 11:09:33 AM Vince Harron <<a href="mailto:vharron@google.com">vharron@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>We completely agree that there should be a continuous build with top-of-everything.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.  </div><div><br></div><div>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.</div><div><br></div><div><div>Thanks,<br></div></div><div><br></div><div>Vince</div><div><br></div></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 18, 2014 at 5:10 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also +1.  I hope to have this going on Windows sometime before the end of the year.  Getting ProcessWindows working at least with minimal functionality is one of the last major hurdles.<div><div><br><br><div class="gmail_quote">On Tue Nov 18 2014 at 5:06:22 PM Kate Stone <<a href="mailto:katherine_stone@apple.com" target="_blank">katherine_stone@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I've made a point of prioritizing getting our tests to run cleanly here, so it would be a good time for the community to do likewise for other platforms.  Among other benefits, Improving the signal/noise ratio for test failures will make the message to LLVM a lot clearer.<br><br><div style="word-wrap:break-word"><span style="background-color:rgba(255,255,255,0)"><font>Kate Stone</font> <font><a href="mailto:k8stone@apple.com" target="_blank">k8stone@apple.com</a></font></span></div><div style="word-wrap:break-word"><span style="background-color:rgba(255,255,255,0)"><font></font> Xcode Runtime Analysis Tools</span></div></div></div><div dir="auto"><div><br>On Nov 18, 2014, at 4:57 PM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 18, 2014 at 3:15 PM,  <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I actually think it is good that incompatible changes to llvm break the lldb build bots right away.  Then they will get fixed in lldb right after the change was made when it is clear in people's minds what just went on.  So I wouldn't want to add any of this sort of machinery to lldb's build w.r.t. the build bots.  Now that the build-bots are running regularly, the clang folks can also see the breakage right away and just fix it, which they often do (thanks for that BTW...)  So if there were a "GOOD_LLVM" it should not be used for the build-bots.<br></blockquote><div><br></div><div>+1, LLDB breakages need to be more visible to Clang/LLVM developers. Currently they are not very visible, mostly for no good reason.</div><div><br></div><div>Stabilizing the LLDB test suite would help, but the bots could probably be more aggressive about sending IRC or email pings when the build (not tests) fails, as this is the primary way that LLVM and Clang changes break LLDB.</div></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>lldb-dev mailing list</span><br><span><a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a></span><br><span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a></span><br></div></blockquote></div>______________________________<u></u>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div><div class="gmail_extra">-- <br><div><div dir="ltr"><br><table cellspacing="0" cellpadding="0" style="font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Vince Harron |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Technical Lead Manager |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:vharron@google.com" target="_blank">vharron@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> 858-442-0868</td></tr></tbody></table><br></div></div>
</div></blockquote></div>