On Mon, 22 Sep 2014, David Malcolm wrote:

> There appears to be a particular implicit order in which headers must be
> included.  I notice that e.g. tm.h has:
> 
>   #ifndef GCC_TM_H
>   #define GCC_TM_H
> 
> so if we're going with this "no header file includes any other header
> file" model, would it make sense to add something like:
> 
> #ifndef GCC_TM_H
> #error tm.h must have been included by this point
> /* We need tm.h here so that we can see: BAR, BAZ, QUUX,
>    etc.  */
> #endif
> 
> to header files needing it, thus expressing the expected dependencies
> explicitly?

In principle, yes.

In practice, some headers have definitions that depend on tm.h but for 
most users this doesn't matter.  For example, flags.h depends on 
SWITCHABLE_TARGET.  (I think the fix there is to make most users use 
options.h instead, and move miscellaneous declarations from flags.h to 
other headers.)  In some cases, the target macro may be used only in a 
macro expansion.  (BITS_PER_UNIT isn't strictly a target macro any more, 
but when it was its uses in tree.h were an example of that.  tree.h still 
depends on the target macros NO_DOLLAR_IN_LABEL, NO_DOT_IN_LABEL and 
TARGET_DLLIMPORT_DECL_ATTRIBUTES, however, but we shouldn't make all 
tree.h users include tm.h.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Reply via email to