> Personally I'd rather that I have to specify 42 include files at the
> top of my module.

I *really* disagree - if nothing else, it would make porting hell,
because every UNIX variant would have its own list of include files
you'd need.  (Go look at a .depend file sometime - unless you've made a
point of grubbing around in the include file mechanisms, I'll bet
you've never even *heard* of some of the files you're including without
knowing it - and that you'd have to know about under this paradigm.)

> It's either that or we could have one header per lib*.a file.

Fortunately, it's actually not as bad as you paint it.  I've been going
thorugh and adding "missing" includes to the include files as I trip
over them.  And while I've doubtless failed to notice some because I
"always" want the "missing" file anyway, and they happen to be such
that my style puts the needed #include before the other...despite that,
I still regularly find that when I start a new program and try to
compile it with no #includes, then start adding them as necessary,
there are at least half a dozen functionally orthogonal sets.  As I
type this, a sweep is running, something almost identical to

( cd /usr/include ; find . -name \*.h -print ) |
sed -e 's;^./;;' |
while read incfn
do
	echo "#include <$incfn>" > z.c
	cc -c z.c 2>&1 | sed -e "s;^;$incfn -- ;"
done

to see what I've missed.

Perhaps I'll find your predictions realized.  Perhaps my guess will be
closer to the truth.  Once the run finishes, I'll report....

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B