include files -- help needed

[Guthrie;Wade]

I have this quandry regarding include files in a large (I mean *REALLY* 
large) software system.  The software team with which I am working is
developing a few hundred thousand line project which is broken up into 
several...let's call them "chunks".  The chunks communicate with each 
other by passing (message-specific) packets which are described by 'C'
structures.  The problem we face is managing the include files for the 
interface structures.  

We have around 15 chunks each of which must interface with several other 
chuncks (many of the chunks are things like utilities, BIT, database, 
stuff like that).  Beyond this, the software must interface with the 
operating system to deal with system resources, semiphores, inter-process
queues, etc.

In order to follow the guidelines of

	1) no nested include files and
	2) limiting the scope of globals and typedefs,

we have come up with an abysmally complex array of include files.  We
have essentially two include files for each pair of chunks (e.g., 
BIT-to-database and database-to-BIT interface definitions), an array of 
include files for constants, and another array for system resources.  A 
further problem arises when, for example, the "utilities" chunk has a 
common output format between itself and both BIT and database.

My question is this: How do other projects deal with this problem?  What
is used to partition the include files to try to keep the list of files 
small and at the same time limit the exposure of information (global data 
and type definitions) to chunks that do not use that information?  I am 
particularly interested in solutions used for big projects (e.g., BSD).

Thank you ever so much in advance.
-- 
Wade Guthrie (evil at arcturus.UUCP)    | "The likelihood of one individual being
...uunet!ccicpg!felix!arcturus!evil  | right increases with direct proportion to
Rockwell International; Anaheim, CA  | the intensity with which others are trying
My opinions, not my employer's.      | to prove him wrong", Mr. Jordan