On Sun, May 15, 2011 at 6:26 AM, Ruben Van Boxem <vanboxem.ru...@gmail.com> wrote: > Wow, I think I have a partial solution. Delving into the Python docs, > for example here: > http://docs.python.org/using/windows.html#finding-modules, you can see > that PYTHONPATH is used first, then the Windows registry, then > PYTHONHOME, then some default relative paths. I placed the python > scripts all in the directory structure like so: > > /bin/gdb > /bin/Lib/<python scripts> > /bin/python27.dll > > This works, even without any manual PYTHONPATH intervention. Problem > is though, that as soon as someone has a PYTHONPATH environment > variable from a (incompatible) Python installation (think different > bitness or version 3.x instead of 2.7.1), I cannot predict what will > go wrong. This problem originates in Python's way of filling in the > search path (sys.path). A true solution in the GDB case to prevent > this collision of an incompatible PYTHONPATH would be that GDB sets an > internal PYTHONPATH as directed by configure, uses that to load its > Python internals, and allows the GDB child processes (apps being > debugged) to use the environment PYTHONPATH. For now, I have a > functional installation, but it will break as soon as someone installs > Python on their system.
What if the user *wants* gdb's python to use $PYTHONPATH from his/her environment? To handle *this* case, *and* the case of an incompatible python installation using $PYTHONPATH, there is the $GDB_PYTHONPATH proposal (see earlier email for details). It feels problematic to decide at configure time whether there will or will not be an incompatible python at runtime. [I realize you have subsequent messages. Just replying in sequence.] -- http://mail.python.org/mailman/listinfo/python-list
