From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: Andrew Cagney Cc: GDB Discussion Subject: Re: GDB's #include file policy Date: Wed, 21 Mar 2001 15:59:00 -0000 Message-id: References: <3AB00410.324AB111@cygnus.com> X-SW-Source: 2001-03/msg00113.html On Wed, 14 Mar 2001, Andrew Cagney wrote: > Several recent patches have prompted the question of what guidelines, if > any, are there for GDB and its include files. > > I think the short answer is that it hasn't had one and people have > simply done what was necessary to keep it building. I'd like to tighten > this, just a little, so that people don't need to guess what goes where > so here goes... I think this should go into gdbint.texinfo. If the text you've posted is all there is to it, I will convert it to Texinfo and add to the manual; if not, please tell what else we should have there. > Outside of "defs.h", GDB header files should try to be self contained > (struct foo * VS typedef ...). If a header file uses typedefs from > another GDB header (but not defs.h) then that should really be dragged > in. I bumped into one problem with the current headers which I was unable to solve easily: If you want to declare a prototype for a function which accepts an argument of the type `enum target_hw_bp_type', you need to include breakpoint.h, where that enum is defined. However, including breakpoint.h is not for the faint of heart: it wants to pull in everybody and their dog, which triggers compiler warnings and other atrocities. The above enum is required for any header which declares prototypes of functions that deal with watchpoints. After trying several solutions (which didn't work in interesting ways), I finally gave up after I noticed that all the other files which needed that simply cheated and declared the argument as an int instead. I think such cheats isn't the way we want GDB code to be written. Perhaps someone could make basic data types defined by breakpoint.h more accessible. > (Now the tricky bit) GDB headers should try to avoid sucking in system > header files. Why? Unlike GDB headers, including more system headers doesn't really hurt, as it doesn't cause unnecessary recompilation. And system headers are idempotent anyway. The problem with this request is that you might need some definition, such as size_t, which you cannot have without a system header. If defs.h is supposed to take care of that, it might be trouble waiting to happen: someone changes defs.h some day, and then all kinds of platforms start breaking. > I think the pratical reality is that > either "defs.h" will have already dragged the header file in () > or that a .C rather than a .H file should be doing the include. The latter possibility has a disadvantage of forcing specific order of header inclusion: you cannot safely include a GDB header before the system header which defines some of the stuff the GDB header uses. > "tm.h" and "xm.h" are definitly on the way out. > "nm.h" is probably heading the same way. What will replace them?