From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25213 invoked by alias); 21 Jun 2005 22:01:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25052 invoked by uid 22791); 21 Jun 2005 22:01:05 -0000 Received: from lakermmtao03.cox.net (HELO lakermmtao03.cox.net) (68.230.240.36) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 21 Jun 2005 22:01:05 +0000 Received: from white ([68.9.64.121]) by lakermmtao03.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050621220103.ZTQL18229.lakermmtao03.cox.net@white>; Tue, 21 Jun 2005 18:01:03 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1Dkqnn-0001lL-00; Tue, 21 Jun 2005 18:01:03 -0400 Date: Tue, 21 Jun 2005 22:01:00 -0000 From: Bob Rossi To: Nick Roberts Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [PATCH] MI error messages Message-ID: <20050621220103.GA6754@white> Mail-Followup-To: Nick Roberts , Eli Zaretskii , gdb-patches@sources.redhat.com References: <20050619145612.GA8219@nevyn.them.org> <17077.61587.164352.664225@farnswood.snap.net.nz> <17078.19977.660644.9978@farnswood.snap.net.nz> <20050620135108.GA29453@nevyn.them.org> <17079.14386.484824.134375@farnswood.snap.net.nz> <17079.57494.321274.96102@farnswood.snap.net.nz> <17080.35377.519988.619664@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17080.35377.519988.619664@farnswood.snap.net.nz> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-06/txt/msg00339.txt.bz2 On Wed, Jun 22, 2005 at 09:44:17AM +1200, Nick Roberts wrote: > Eli Zaretskii writes: > > > Which file should mi_error/mi_usage_error go in? mi-cmds.c seems the best > > > option to me as the mi-cmd-*.c files include mi-cmds.h. > > > > I don't care much, but isn't mi-common.c a better place? > > mi-common.c seems a bit of a misnomer. Perhap common here means frequent > rather than shared. mi-common.h isn't included in any of the c files apart > from mi-common.c Well, I just added mi-common. It was intended to be an interface for the rest of GDB to be able to get constant string data or MI specific enumeration values from the MI code. It could also be used for common data for the MI internals itself, but I would probably advice against that. It might be nice to add another file that allows the internals of the MI code to share data and such. Bob Rossi