From: Joel Brobecker <brobecker@adacore.com>
To: Doug Evans <dje@google.com>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>,
gdb-patches@sourceware.org, David Malcolm <dmalcolm@redhat.com>
Subject: Re: [RFA] ignore PYTHONHOME environment variable.
Date: Tue, 23 Nov 2010 17:31:00 -0000 [thread overview]
Message-ID: <20101123173054.GW2634@adacore.com> (raw)
In-Reply-To: <AANLkTi=W+PnwOfNkRRe5OMz0qm5vCghhduO5ve1Qk3zH@mail.gmail.com>
> <jan.kratochvil@redhat.com> wrote:
> > But PYTHONHOME=$HOME for some user overrides of system Python would
> > no longer work. Â What would $PYTHONHOME otherwise be useful for?
>
> OTOH what if one wanted to debug a python with a different PYTHONHOME?
> GDB_PYTHONHOME? [not my idea, but seems reasonable]
I think you indeed need something like that. I don't think we can trust
PYTHONHOME, because it might point to something that's incompatible.
GDB_PYTHONHOME is something that got suggested by at least 2 people
(someone at AdaCore also suggested it a while back). I have to wonder,
though, why you would want to run GDB with a different version of Python
than then one used to build GDB with. If you want to use your own
scripts, you can use the PYTHONPATH.
Still, we can add that too, something like that:
#ifdef WITH_PYTHON_PATH
if "GDB_PYTHONHOME" is defined
Py_SetPythonHome (getenv ("GDB_PYTHONHOME"));
else
/* We override any value that the PYTHONHOME might have, as we want
to make sure that we use the Python library that comes with GDB. */
Py_SetPythonHome (ldirname (python_libdir));
#endif
But I think I would prefer something like this:
if "GDB_PYTHONHOME" is defined
Py_SetPythonHome (getenv ("GDB_PYTHONHOME"));
#ifdef WITH_PYTHON_PATH
else
/* We override any value that the PYTHONHOME might have, as we want
to make sure that we use the Python library that comes with GDB. */
Py_SetPythonHome (ldirname (python_libdir));
#endif
The latter makes GDB_PYTHONHOME always active, regardless of how
GDB was linked against Python.
--
Joel
next prev parent reply other threads:[~2010-11-23 17:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 1:03 Joel Brobecker
2010-11-23 3:01 ` Jan Kratochvil
2010-11-23 9:29 ` Doug Evans
2010-11-23 16:31 ` Jan Kratochvil
2010-11-23 16:57 ` Doug Evans
2010-11-23 17:31 ` Joel Brobecker [this message]
2010-12-14 7:12 ` Joel Brobecker
2010-12-14 9:27 ` Jan Kratochvil
2010-12-14 10:33 ` Joel Brobecker
2011-01-13 22:57 ` Joel Brobecker
2011-01-15 9:17 ` Doug Evans
2011-01-15 11:26 ` Jan Kratochvil
2011-01-17 10:36 ` Joel Brobecker
2012-05-18 19:34 ` Jan Kratochvil
2012-05-28 14:41 ` Joel Brobecker
2012-05-28 17:30 ` Jan Kratochvil
2012-05-29 14:54 ` Joel Brobecker
2012-05-29 15:57 ` Jan Kratochvil
2012-05-30 14:37 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101123173054.GW2634@adacore.com \
--to=brobecker@adacore.com \
--cc=dje@google.com \
--cc=dmalcolm@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox