[lldb-dev] Green Dragon LLDB Xcode build update: TSAN support
Pavel Labath via lldb-dev
lldb-dev at lists.llvm.org
Wed Apr 6 01:42:59 PDT 2016
On 6 April 2016 at 06:23, Todd Fiala <todd.fiala at gmail.com> wrote:
> Okay, thanks all.
>
> 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).
I've been running them locally, and I haven't noticed any flakyness.
It should be also be much easier to remove it, if we find any, because
of the smaller scope and number of tests.
>
> 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.
In cmake, you can run these tests with the check-lldb-unit target. I
like the idea of being able to run both, but I think we should also
keep the option of running them separately. How about:
check-lldb: runs unit and python tests
check-lldb-unit: runs unit tests only
check-lldb-XXX: runs only python tests (for some value of XXX)
>
> 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).
+1
More information about the lldb-dev
mailing list