On Fri, 6 Sep 2013, Richard Biener wrote:

> But yes, making all dependencies explicit puts #includes where they 
> belong and shows where header refactoring would make sense.  It also 
> removes weird includes from .c files that are only necessary to make 
> included required headers not break.

One difficulty is that e.g. flags.h uses SWITCHABLE_TARGET (tm.h) but is 
included in lots of front-end files that don't actually care about the 
SWITCHABLE_TARGET use in flags.h and have no other reason to include tm.h.  
Since we generally want to eliminate tm.h uses in front-end files 
(converting target macros used there into hooks, etc.), making the 
"dependency" explicit in the obvious way isn't such a good idea.  
Instead, probably the bits that don't depend on SWITCHABLE_TARGET should 
move out of flags.h to other headers, the residual bit that does depend on 
tm.h should become e.g. switchable-target-flags.h (and include tm.h), and 
files that currently include flags.h should change to including the 
generated options.h (and any other headers needed for things formerly got 
from flags.h).

(If other headers do start including tm.h, of course it becomes more 
complicated to identify which front-end files are still including tm.h, as 
they may include it indirectly.)

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

Reply via email to