Re: RFC: add ability to "source" Python code

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Sun, 8 Feb 2009 17:52:46 -0800
> From: Doug Evans <dje@google.com>
> Cc: tromey@redhat.com, gdb-patches@sourceware.org
> 
> On Sat, Feb 7, 2009 at 8:08 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > However, I don't think I like the idea of GDB barfing if Python
> > support is not compiled in.  I think it should simply try to interpret
> > the file as GDB scripting commands.
> 
> I 3/4 disagree.  :-)
> 
> In the case of "source -p foo", I disagree.  This is new functionality
> (*1), and silently (or otherwise) interpreting "source -p foo" as gdb
> scripts will lead to subsequent breakage if/when python support does
> get compiled in.  [That's 1/2 of the 3/4.]
> 
> In the case of "source foo.py" I sort of disagree (that's the other 1/4, fwiw).
> Technically speaking it's possible that some bloke out there has a
> foo.py script that actually is gdb commands, and forcing the script to
> be interpreted as python would break that.  It's seems really unlikely
> though.
> 
> Perhaps "source" could/should also take a -g option to force the
> script to be interpreted as gdb commands.  It mightn't be sufficient
> to justify breaking an existing "source foo.py" being interpreted as
> gdb commands (though I think it is), but it might be reasonable to add
> anyway.
> 
> [(*1): And if we're worried about breaking existing usage, do we also
> need to worry about someone with a script named "-p foo.gdb"?

To clarify, I think "source" without Python compiled should behave
exactly as it did before this patch: treat foo.py as any other file
name and treat -p as it does today (i.e. source "-p foo.gdb" if it
exists).

Yes, this is called "backward compatibility".  It just could be that
one reason why someone configures GDB without Python is that they
don't want this incompatible change.