C project structure - header-per-module vs. one big header

Question

I've worked with a number of C projects during my programming career and the header file structures usually fall into one of these two patterns:

1. One header file containing all function prototypes
2. One .h file for each .c file, containing prototypes for the functions defined in that module only.

The advantages of option 2 are obvious to me - it makes it cheaper to share the module between multiple projects and makes dependencies between modules easier to see.

But what are the advantages of option 1? It must have some advantages otherwise it would not be so popular.

---

This question would apply to C++ as well as C, but I have never seen #1 in a C++ project.

Placement of #defines, structs etc. also varies but for this question I would like to focus on function prototypes.

Answer 1

I think the prime motivation for #1 is ... laziness. People think it's either too hard to manage the dependencies that splitting things into separate files can make more obvious, and/or think it's somehow "overkill" to have separate files for everything.

It can also, of course, often be a case of "historical reasons", where the program or project grew from something small, and no-one took the time to refactor the header files.

Answer 2

Option 1 allows for having all the definitions in one place so that you have to include/search just one file instead of having to include/search many files. This advantage is more obvious if your system is shipped as a library to a third party - they don't care much about your library structure, they just want to be able to use it.