(c)2000 Bram Stolk (b.stolk at host chello.nl)
Sun Sep 24 14:32:12 CEST 2000


This program is licensed under GPL. See the file 'COPYING'.

We'll start with my motto:
"Fear badly constructed include hierarchies!"

Usage: idep dirname extention
e.g.: $ idep /usr/local/src/ppe/src .h

idep can be used for checking the dependencies of C++ include
files. It offers these features:

- Prints out hierarchy of include files
- Lists the class definitions that are found in each header file.
- Detects cyclic dependencies in your include files
- Detects inclusions that could be pruned

The pruning idea is based on the rampant over-including that
many programmers practice. Often, an #include "foo.h" could
simply be replaced by a 'class Foo;' forward reference if Foo
is only used indirectly in the header file (via ptr or ref).

The system will designate a node 'prunable' if none of the
class definitions of the included node are used directly
(without * and &) in the including node. A node without
class defs will never be designated as prunable, as it is
likely to contain vital stuff like typedefs,consts,defines.

BUGS:

* Does not handle '# include' cases as opposed to '#include'

* Does not expand preprocessor macros (like #if and #ifdef)

* Only header files within sourcetree are considered.
  External headers (like /usr/include/stdio.h) are ignored.

* Pruning only checks for dependencies on class definitions.
  This means that other definitions like typedefs, consts,
  defines etc are missed: the program will invalidly designate
  nodes as prunable, where they really are not.

* Some headers serve as a 'collector': for a certain subsystem,
  a range of headers are all included into a single headerfile
  for convenience. The idep utility will designate a collector
  header as highly prunable: yet, it is intended this way by
  the programmer in question. Please note that collector headers 
  are bad practice and should be avoided anyway! Include nothing'
  more than you actually need.

     Bram

