From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5602 invoked by alias); 9 Apr 2003 20:56:14 -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 5595 invoked from network); 9 Apr 2003 20:56:12 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (205.232.38.116) by sources.redhat.com with SMTP; 9 Apr 2003 20:56:12 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id D6F62D34B8; Wed, 9 Apr 2003 16:56:11 -0400 (EDT) Date: Wed, 09 Apr 2003 20:56:00 -0000 From: Joel Brobecker To: David Carlton Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] missing #include in frame.h? Message-ID: <20030409205611.GP1170@gnat.com> References: <20030409203842.GN1170@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2003-04/txt/msg00177.txt.bz2 > My impression is that the right thing in these situations is normally > to put an opaque declaration of the struct in question at the top of > the header file: > > struct gdbarch; > > That way, header files can be included in any order without forcing > them to include each other. This makes sense. Thanks. > But shouldn't all .c files inculde defs.h first? (Indeed, that's what > GDB Internals says.) Which file were you compiling when you got this > error? Probably that file should be fixed to include defs.h before > frame.h, instead of changing frame.h. Ugh (excuse my French). If bla.h depends on defs.h, I think it is wrong to ask all c files including bla.h to include defs.h first... But I come from the Ada world, so maybe there is a good reason for this? I dug a bit further, as my conclusions were a bit premature. Here is one include stack example when this happens: In file included from breakpoint.h:25, from gdbthread.h:29, from config/nm-lynx.h:49, from nm.h:24, from defs.h:767, from frame.c:23: I checked frame.c, and it does include defs.h before frame.h. What actually happens is that nm.h is indirectly including frame.h before defs.h has included gdbarch.h... (nm.h = config/i386/nm-i386lynx.h, which is equivalent to config/nm-lynx.h). I think the best approach at this point is really to add the opaque structure definition. -- Joel