aprantl added a comment.
> The advantage of the second one is that we will have the ability to inject
> commands which depend on the results of previous commands (something that I
> think we will need, sooner or later).
That is worth considering. To write good tests that depend on previous results,
we probably want to have SBAPI-like Python scripting for lldb-mi available. To
make that work we would need to introduce an lldbmi.HandleCommand("-mycmd...")
interface that runs one command, blocks on it, and returns the output in a
string. And then we would need to export that to Python. Since the interface is
string-in-string-out, we could probably do it via C without even involving
SWIG. As an escape hatch to access features outside of the mi command set, we
could implement the -interpreter-exec mi command that passes its input to
SBAPI's HandleCommand() if need be.
Alternatively we could use gtest to write unittest-style lldb-mi tests directly
in C++, if going via Python is too messy. Again, we would do that in a blocking
or synchronized I/O mode.
Repository:
rL LLVM
https://reviews.llvm.org/D46588
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
