Having a kitchensink.h or whole_enchilada.h is almost always a very bad idea. When I'm browsing through a package and see such a monster I take that as a sign of a poorly designed chunk of software.
Much better is to make your header files include the header files that are needed by that header. Example: Suppose file bar.h defines the class Bar, one of whose data members is of type Foo. Class Foo is defined in the file foo.h. In this case, the file bar.h should contain a #include "foo.h" directive. On the other hand, if the dependencies to class Foo in bar.h are only in the form of pointers or references to instances of Foo, then bar.h should not #include foo.h. All that is needed is a forward declaration of the class. In your source files, you should include only the headers that define the external functionality needed by that source file. You should not have to include the headers needed by those headers if you developed your header files correctly.
What if you need to include dozens and dozens of header files in a single file? That too is a sign of a bad design. It's called excessive fan-out. A fan-out of more than 7±21[/color] is a sign of problems. A fan-out in the dozens is a sign of big problems.1[/color]George Miller, "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information", Psychological Review 63 (2): 81–97 (1956).