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/ _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
