[Lldb-commits] [PATCH] Python split [1/2] - File renames

[Zachary Turner]

In http://reviews.llvm.org/D7956#134403, @clayborg wrote:

> It seems like "lldb/Interpreter/ScriptInterpreter.h" still exists in your tree and you are able to compile because it is still there? It isn't there for me and there are 20 locations that are still trying to include it.
>
> After fixing 100 or so build errors I am giving up on this patch. Please try to make it work for MacOSX. The major issues are:
>
> - There is no need to create a new "include/lldb/ScriptInterpreter" directory it will just make merges very hard for us and it gains us nothing since only abstract virtual classes should be in there (and a default implementation for None)


So leave it in Interpreter?  I'm fine with that, I just don't want it to be under the API folder, since it should be accessible even when API is not built.

> - Where ever there is a #ifndef LLDB_DISABLE_PYTHON, this will need to be abstracted to go through the abstract ScriptInterpreter class for the current language.


Agree, but this is a MUCH larger change, and I wanted to take the steps incrementally.  That has been the end goal all along, but it's too much to do all at once.

> - No one should be including ScriptInterpreterPython.h anywhere, they should just use the current ScriptInterpreter subclass gotten from the interpreter and anything that was being done using a special version of this class should be abstracted through ScriptInterpreter


Same as before, I agree, but that's a much larger change.  This is only intended to be a first step.

> - cases like ProcessGDBRemote::ParsePythonTargetDefinition(const FileSpec &target_definition_fspec) should find the script interpreter for the target definition file and call through the abstract ScriptInterpreter class to parse it  somehow


Same as before.


http://reviews.llvm.org/D7956

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/