In D61090#1477912, @jingham wrote:

It seems weird to be getting the ScriptInterpreter's ScriptModuleDirectory from the CommandInterpreter. I would have expected:

m_debugger.GetScriptInterpreter().GetScriptModuleDirectory()

I don't think there's any reason to have the Command Interpreter know which ScriptInterpreter is being used, so entangling them like this is awkward.

Am I missing some reason why it makes sense to do this on the CommandInterpreter?

(I didn't yet, but I'll cleanup the references to Python in the driver if people like this approach.)

Deprecate the current method in SBHostOS and provide an alternative through SBCommandInterpreter::GetModuleDirectory

LGTM

Thanks!

In D60780#1468927, @labath wrote:

LLDB_TOOL_$TOOL_BUILD would be a better name for consistency with llvm. In fact, if we started using the llvm cmake macros like add_llvm_subdirectory, it would handle this automatically, including creating the cache variable.

The only difference would be that the variable would default to "On", whereas you seem to want default-off. (I'm a bit torn on whether this is good. On one hand, I understand the desire to not build this stuff, but on the other, this creates an inconsistency with llvm, which builds everything by default, and consistency is a good thing.)

Also, I'd like to nominate lldb-mi as an additional optional feature. :)

We need to define these variables in the cache and make sure the test suite knows about them.

Thanks for doing this, Raphael!

Makes sense, LGTM

Feedback Pavel

Apparently Pavel already investigated and fixed this in r357459. We also discussed a better way to make this work by checking the echo of the command passed to sendline.

To give a little more context: the particular issue I was looking at (TestCommandScriptImmediateOutput) occurs with sendline. We send a bunch of commands and always check for the prompt. I can reproduce the error when piping the test commands directly to LLDB.

LGTM with the outstanding comments/questions addressed.

In D55718#1453084, @tatyana-krasnukha wrote:

Hi, currently we have a private build server that executes the test-suite on ARC. There are failures for now, mostly due to unimplemented features for ARC like expressions support.
I'll take care of a public build-bot, if it is required.

LGTM

In D60442#1459378, @kkleine wrote:

I think I don't have commit access (yet) and would like if someone can commit this for me. It was my first commit to the LLDB project and I wanted to get familiar with phabricator and the arc tool. Is phabricator here to stay or are there plans to move to github or something else? I'm just a bit confused still about some SVN revisions showing up here and there and why that is. I guess it will clear up in some time.