Re: [python] proper setting of sys.path

[Tom Tromey <tromey at redhat dot com>]

>>>>> "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