> On Jul 31, 2017, at 5:04 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote: > > On Mon, Jul 31, 2017 at 9:27 PM, Darin Adler <da...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
