[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

[Zachary Turner via lldb-commits]

On Tue, Sep 19, 2017 at 7:12 PM Jason Molenda <jmolenda at apple.com> wrote:

>
>
> > On Sep 19, 2017, at 6:57 PM, Zachary Turner via lldb-commits <
> lldb-commits at lists.llvm.org> wrote:
> >
> >
> >
> > After some additional thought, I stilled think testing below the sb api
> layer is more appropriate.
> >   While Xcode might be going through the SB api, users of upstream lldb
> (which is what we supposed to be testing upstream) are not.
>
>
> One thing to keep in mind is that while Xcode is the IDE using lldb that
> Apple directly supports, there are many other IDEs that are using lldb
> today.  I don't know for certain that all these are using SB API, but a
> partial list of additional IDEs in addition to Xcode includes CLion ("A
> Cross-Platform IDE for C and C+ by JetBrains"), Nuclide (atom based IDE),
> Android Studio, Visual Code Studio, and Eclipse (I know this one is done
> via lldb-mi).
>
> Command line lldb is the interface I personally tend to prefer, but it is
> not the interface that the vast, vast majority of our users use when
> debugging with lldb.  SB API is.  The lldb driver is more akin to one
> front-end among many, and an odd one, given that it doesn't go through the
> SB API itself.
>

Definitely, but that's also one reason I think it's so important to split
the tests up.  Right now there is almost no coverage of not going through
the SB API, and yet that is the interface that we, as the upstream
open-source project, provide to users.  And while it may not be the
interface that the vast majority of users *currently* use, I think if we
compared the number of people using GDB to the number of people using LLDB,
it paints a different picture.  Namely, a picture of how many users *could*
be using LLDB.

I don't want to break any existing users of LLDB obviously, including those
that go through the SB API, but at the same time the primary product that
comes out of the open-source project is, in fact, a command line debugger,
and we should strive to make that experience as good as possible.

I believe if the tests are split into private tests and public API tests
you get the best of both worlds.  I would even go farther to say that the
whole is greater than the sum of parts, because it makes it easy to write
tests for any new api that comes along, and vastly reduces the barrier to
entry to writing new tests, which I still believe is one of the most
critical bugs facing the project today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170920/d75b1cf5/attachment.html>