<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 7, 2017 at 11:40 AM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Sep 7, 2017 at 11:34 AM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Even if it were under llvm, that doesn't mean it would have to be part of ninja check-all.  Currently we have lldb/test and lldb/unittests, what about a third lldb/dbgtests?  Then you could run it as ninja check-dbgtest.</div></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div><br>Having them in lldb seems like an interesting question - not sure what the value is in having them in a separate repo compared to having them in the LLDB project. (I mean, long term, I think LLDB testing should probably have fewer of these end-to-end tests (ideally few tests that actually run a compiler/execute a resulting program (avoiding that so the tests are more portable, reliable, etc)) - but it's reasonable to have some & probably OK that they live in the LLDB repo (for LLVM these sort of tests live separately in the test-suite repo)<br><br>Maybe because it makes the tests more likely to be run, more reliable (so they don't fail due to LLDB changes - makes it easier for Clang/llvm developers to act on regressions, etc)</div></div></div></blockquote><div><br></div><div>Sorry, I had a bad typo.  I meant we have llvm/test, llvm/unittests, so what about llvm/dbgtests.</div><div><br></div><div>I definitely woudln't want them in LLDB, as my entire motivation is to write tests against a non-LLDB debugger. </div></div></div>