From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14780 invoked by alias); 9 Feb 2009 04:09:52 -0000 Received: (qmail 14772 invoked by uid 22791); 9 Feb 2009 04:09:51 -0000 X-SWARE-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,BAYES_00,BOTNET,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout1.012.net.il (HELO mtaout1.012.net.il) (84.95.2.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Feb 2009 04:09:42 +0000 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KES00B0062B4Y00@i-mtaout1.012.net.il> for gdb-patches@sourceware.org; Mon, 09 Feb 2009 06:08:44 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.128.7]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KES00HDV66JS3C0@i-mtaout1.012.net.il>; Mon, 09 Feb 2009 06:08:44 +0200 (IST) Date: Mon, 09 Feb 2009 04:09:00 -0000 From: Eli Zaretskii Subject: Re: RFC: add ability to "source" Python code In-reply-to: To: Doug Evans Cc: tromey@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: References: X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00198.txt.bz2 > Date: Sun, 8 Feb 2009 17:52:46 -0800 > From: Doug Evans > Cc: tromey@redhat.com, gdb-patches@sourceware.org > > On Sat, Feb 7, 2009 at 8:08 PM, Eli Zaretskii 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.