This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [python] proper setting of sys.path
>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:
Tom> From the Python API reference, it sounds as though we ought to call
Tom> Py_SetProgramName(argv[0]) early on.
Tom> Will this work for your case?
Paul> Yes, I've looked at this as well, and doing so would require
Paul> that argv[0] be passed to all the _initialize_YYYY(), which are
Paul> auto-generated from a sed script.
I think we could arrange a special initialization call just for
this -- a function that would be called before _initialize_python.
Paul> Yes, this would work in my case, but only so long as I don't copy
Paul> the GDB/Py binary into /usr/bin. As soon as I do that, I'd be back
Paul> to square one :(
Paul> An alternative which will continue to work regardless of where my
Paul> GDB binary is copied, is to use $HOME/python2.4/bin/python in call
Paul> to Py_SetProgramName() (where the path to python is the one which
Paul> was detected at GDB configure time).
I see.
I suppose the underlying question is -- what kinds of deployments do
we want to support?
I think at least three:
1. The distro case: python and gdb are both in /usr.
2. The gdb-hacker-using-a-distro case: python is in /usr and gdb is not.
3. The toolchain vendor case: python and gdb are installed in the same
$prefix, which is relocatable as a whole.
These are basically the ones that are historically supported, I think.
We do ok for #1 and #2, but maybe not #3.
We could try to support your case, which I would say is: python is in
$prefix1 and gdb is in $prefix2. Perhaps #3 is a special case of
this. For instance, we could use the compiled-in python directory,
but run it through the same path-relocation process that we use for
GDB_DATADIR et al.
Paul> I think that the root cause of the difficulty is that python is
Paul> using a heuristic to find modules, and the heuristic works well
Paul> when argv0 is the interpreter, but less well when argv0 has nothing
Paul> to do with the interpreter being used.
Yeah. I don't think every possible deployment scenario is supportable
without resorting to having the user set PYTHONPATH.
Paul> Yet another alternative is to remove assumption about availability
Paul> of standard python modules. In the past, you could just copy the
Paul> single GDB binary to target system, and it worked (i.e. there was no
Paul> "make install" requirement). And now we are breaking that :(
I've tried to make it so that the python-enabled gdb will degrade
gracefully. By this I mean that if it can't find gdb's python
library, it ought to work.
I haven't investigated what libpython requires at runtime, or tried to
break this. I think Python's rich library is one of its major
attractions as a gdb scripting language; happy with simply requiring
this to work.
Tom