[lldb-dev] Removing the hard python dependency

[Zachary Turner]

I'm thinking about finishing this work off, because it's still a big
hindrance for running the unit tests on windows.  (not dotest, but the
gtest stuff).  The reason is that gtest works by outputting a separate
executable for every test suite, which means each of those executables
needs to link against python.  Windows doesn't have a good alternative to
LD_LIBRARY_PATH (it only has PATH) so this means it's cumbersome to run the
unittest suite without modifying your PATH variable, which interferes with
the system installed python.

I have a patch locally which removes some unnecessary #includes of
ScriptInterpreterPython.h, and after I submit this patch I think that will
be the last of the references to ScriptInterpreterPython hanging around
somewhere they don't really belong.  The remaining occurrences look like
this:

Find all "ScriptInterpreterPython.h", Match case, Subfolders, Find Results
1, "d:\src\llvm\tools\lldb", "*.cpp; *.h"

D:\src\llvm\tools\lldb\include\lldb\Interpreter\ScriptInterpreterPython.h(1)://===--
ScriptInterpreterPython.h -------------------------------*- C++ -*-===//
  D:\src\llvm\tools\lldb\source\API\SystemInitializerFull.cpp(67):#include
"lldb/Interpreter/ScriptInterpreterPython.h"

D:\src\llvm\tools\lldb\source\Initialization\SystemInitializerCommon.cpp(16):#include
"lldb/Interpreter/ScriptInterpreterPython.h"

D:\src\llvm\tools\lldb\source\Interpreter\CommandInterpreter.cpp(67):#include
"lldb/Interpreter/ScriptInterpreterPython.h"

D:\src\llvm\tools\lldb\source\Interpreter\PythonDataObjects.cpp(26):#include
"lldb/Interpreter/ScriptInterpreterPython.h"

D:\src\llvm\tools\lldb\source\Interpreter\ScriptInterpreterPython.cpp(19):#include
"lldb/Interpreter/ScriptInterpreterPython.h"
  Matching lines: 6    Matching files: 6    Total files searched: 1864

I know we had talked about moving ScriptInterpreterPython and
PythonDataObjects to source/API/bindings.  I think that will be sufficient
for us, but that still leaves SystemInitializerCommon,
SystemInitializerFull, and CommandInterpreter to worry about.

For the first two I think I can solve this by removing the dependency from
the unit test executables to lldbInitialization (which is why I created
this library in the first place).  After all, unit tests are only testing
very simple data structures, they don't need to initialize anything.

But I'm still a little unsure about what to do about the final reference in
CommandInterpreter.

It all boils down to this function

ScriptInterpreter *CommandInterpreter::GetScriptInterpreter (bool
can_create)

I think that what is necessary is to invert the creation responsibility
here.  Instead of having CommandInterpreter::GetScriptInterpreter create
the thing, instead have SystemInitialierCommon or SystemInitializerFull
call SBCommandInterpreter::InitializeScriptInterpreter(), and
SBCommandInterpreter will call some function like
m_spCommandInterpreter->AddScriptInterpreter(ScriptLanguage,
ScriptInterpreter*)

With the above 3 fixes (creating source/API/bindings, removing the
dependency from unit test executables -> lldbInitialization, and pushing
ScriptInterpreter creation from CommandInterpreter to
SBCommandInterpreter), I think this work will finally be done.


Thoughts?  Does this seem like a reasonable approach?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150528/86f2ea94/attachment.html>