<div dir="ltr">Okay, thanks all.<div><br></div><div>FWIW I am running them on the OS X side.  I haven't seen any stability problems yet.  I'd also expect them to be very stable, much more like a compiler test, since there are far fewer parts in a small-scoped C++ unit test (vs., say, our Python tests which are end-to-end and have many moving parts).</div><div><br></div><div>We've talked about it a bit over here, which I think you're alluding to, which is how do we handle them assuming they were treated like any other test (i.e. revert or fix fast if they break).  That implies we need to run them, which means we should make that easy.  (Particularly easy to not forget).  On the OS X side we currently have a target and scheme that will build and run them, but it's a separate target.  I haven't done anything on the Linux side to make that run, although plugging it into the test targets shouldn't be hard.</div><div><br></div><div>I don't think the gtests replace the purpose of our Python tests, but I think there's a wide-open place for them, particularly when initially testing new classes or hard-to-expose places that would be overly cumbersome to test (and therefore don't get tested).</div><div><br></div><div>For now we can see how it goes on the OS X side and see if there are any gotchas we need to watch out for.  I've had the OS X builder build them for quite a while, just not run them until the other day.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 5, 2016 at 3:43 AM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We're not running them yet. I'd like to add that at some point, but I<br>
haven't gotten around to that yet...<br>
<div class="HOEnZb"><div class="h5"><br>
On 5 April 2016 at 09:39, Tamas Berghammer <<a href="mailto:tberghammer@google.com">tberghammer@google.com</a>> wrote:<br>
> I think we don't. If we consider them stable enough for enabling them on a<br>
> buildbot AND we agree to revert changes breaking the unittests then I am<br>
> happy with enabling them (doing it should take very little effort from our<br>
> side). Otherwise I would prefer to wait until we can get them to a stable<br>
> state.<br>
><br>
> On Mon, Apr 4, 2016 at 10:53 PM Todd Fiala <<a href="mailto:todd.fiala@gmail.com">todd.fiala@gmail.com</a>> wrote:<br>
>><br>
>> One more update:<br>
>><br>
>> The Green Dragon OS X LLDB builder now actually runs the gtests instead of<br>
>> just building them.<br>
>><br>
>> The gtests run as a phase right before the Python test suite.  A non-zero<br>
>> value returning from the gtests will cause the OS X LLDB build to fail.<br>
>> Right now, tracking down the cause of the failure will require looking at<br>
>> the console log for the build and test job.  I'm excited to see our gtest<br>
>> test count has gone from roughly 17  to over 100 now!<br>
>><br>
>> Pavel or Tamas, are we running the gtests on the Linux buildbots?<br>
>><br>
>> -Todd<br>
>><br>
>> On Mon, Apr 4, 2016 at 10:49 AM, Todd Fiala <<a href="mailto:todd.fiala@gmail.com">todd.fiala@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi all,<br>
>>><br>
>>> I've made a minor change to the Green Dragon LLDB OS X Xcode build<br>
>>> located here:<br>
>>> <a href="http://lab.llvm.org:8080/green/job/LLDB/" rel="noreferrer" target="_blank">http://lab.llvm.org:8080/green/job/LLDB/</a><br>
>>><br>
>>> 1. Previously, the python test run used the default C/C++ compiler to<br>
>>> build test inferiors.  Now it uses the just-built clang/clang++ to build<br>
>>> test inferiors.  At some point in the future, we will change this to a<br>
>>> matrix of important clang/clang++ versions (e.g. some number of official<br>
>>> Xcode-released clangs).  For now, however, we'll continue to build with just<br>
>>> one, and that one will be the one in the clang build tree.<br>
>>><br>
>>> 2. The Xcode llvm/clang build step now includes compiler-rt and libcxx.<br>
>>> This, together with the change above, will allow the newer LLDB TSAN tests<br>
>>> to run.<br>
>>><br>
>>> If you're ever curious how the Xcode build is run, it uses the build.py<br>
>>> script in the zorg repo (<a href="http://llvm.org/svn/llvm-project/zorg/trunk" rel="noreferrer" target="_blank">http://llvm.org/svn/llvm-project/zorg/trunk</a>) under<br>
>>> zorg/jenkins/build.py.  The build constructs the build tree with a<br>
>>> "derive-lldb" command, and does the Xcode build with the "lldb" command.<br>
>>><br>
>>> Please let me know if you have any questions.<br>
>>><br>
>>> I'll address any hiccups that may show up ASAP.<br>
>>><br>
>>> Thanks!<br>
>>> --<br>
>>> -Todd<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> -Todd<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div>