[webkit-dev] What's the rationale for not including config.h in any header files?

Maciej Stachowiak mjs at apple.com
Mon Jul 31 14:16:15 PDT 2017

> On Jul 31, 2017, at 5:04 PM, Michael Catanzaro <mcatanzaro at igalia.com> wrote:
> On Mon, Jul 31, 2017 at 9:27 PM, Darin Adler <darin at apple.com> wrote:
>> I don’t think we should add lots of includes of “config.h”, though. I think we can come up with something better.
> Like what? The only alternative is to pass defines as preprocessor flags via -D. Our command lines are already hard enough to read as it is. Or, well, we could include config.h in Platform.h, where the ENABLE/USE series of macros are defined.
> I'm curious as to why including config.h in the header file would break Autotools builds. I don't see why that would be the case. As far as I know, it just happens to be common practice to include config.h only in source files. It's special: you always include it first in source files to avoid extremely confusing bugs that can result from not doing so, and therefore it seems redundant to put it in header files.
> I wonder how other projects (and other IDEs, e.g. XCode) handle this situation. Anyway, I don't have a strong opinion either way....

I think "config.h" as the first body include, and never in headers, is mostly just a stylistic choice in projects that use autotools.

However, here are some specific issues to consider:
(1) Public API headers (or installed private interfaces) should not include config.h, and should not rely on any macros defined there.
(2) It's probably ok to include it in non-API headers, at least any that use macros defined by config.h.
(3) Implementation files may need to still include config.h. They might not include any headers that include config.h, or they might currently but don't want to rely on it. config.h may also define macros that affect the behavior of system headers and therefore should be included before any of them, so it needs to go first.
(4) Given combo of (2) and (3), some includes of config.h in headers may be redundant. I am not sure if this causes any practical problems though.

 - Maciej

More information about the webkit-dev mailing list