Jens Schweikhardt said:consider a small project of 100 C source and 100 header files.
The coding rules require that only C files include headers,
headers are not allowed to include other headers (not sure if
this is 100% the "IWYU - Include What You Use" paradigma).
The headers contain only what headers should contain:
prototypes, typedefs, declarations, macro definitions.
The problem: given a set of headers, determine a sequence of
#include directives that avoids syntax errors due to undeclared
identifiers. I.e. if "foo.h" declares type foo_t and "bar.h" uses
foo_t in a prototype, "bar.h" must be included before "foo.h".
I have been reading the many comments in this thread with some
interest. Reading through your responses, I have come up with
this summary of motivations for using this approach (these are
my paraphrasings, often not quotes of the originals):
+ no lint warnings about repeated headers
+ no need for include guards
+ doxygen dependency graph much simpler
+ no cycles in include graph
+ removing unneeded includes is easier
+ simpler compiler diagnostics
+ easier to generate dependency makefile
+ improved identifiability of refactoring opportunities
+ ... and of interface accumulation [not sure what this means]
+ ... and of code collecting fat
+ constant reminders of all dependencies of each .c file
1. Is this an accurate summary?
2. Has anything been left out (ie, is there any other
positive you would add to the list)?
3. Would you mind listing these from most important
to least important, and giving some indication of
relative weight for each item?
I'm not a computer scientist, but it sounds as if this requires a
topological sort of all the '"foo.h" needs "bar.h"' relations.
Now the interesting part is: how to automate this, i.e. how to
determine "this header declares identifiers A, B, C and requires
X, Y, Z"? [IWYU by google was looked at but seems not a good
Yes, a topological sort. The topological sort is the easy
part - the harder part is identifying what the first-level
Can you think of a lightweight way to solve this? Maybe using
perl, the unix tool box, make, gmake, gcc, a C lexer?
I may have some suggestions here, but first I would like to read
through responses to the questions asked above, to make sure I'm
going in a good direction.