> See, now you have 3 files, the .h/.c file pair of the library, and your own implementation source file with the configuration which includes a .c file. The t

> See, now you have 3 files, the .h/.c file pair of the library, and your own implementation source file with the configuration which includes a .c file. The third source file is what the library authors suggested; I'd just create a seperate Makefile target for the implementation, which is then linked into the binary. (Yes, that's an extra target, but that costs very little and allows you to avoid unnecessary rebuilds.) Why don't you give me a concrete counterexample where the single-header-setup makes things simpler? If it's so obviously beneficial it shouldn't be so hard to come up with a concrete example. > #define IMPLEMENTATION > #include "base_library.h" > #include "extension_library.h" Thanks for explaining, but that doesn't really motivate having a single file, since you could just as easily do: #include "base_library.c" #include "extension_library.c" And you've saved a line (and removed the need for obscure preprocessor macros). > ... without having to add a separate 'private but actually public API'. Personally, I'd say this is exactly the right way to model this, but even if you disagree: it sounds like this simplifies things mainly for the library/extension authors, and not the library users, because if the extension author forward-declares the implementation details they depend on, there is no additional file to manage for the users either.