Hi, > I wonder if we should instead use headers like: > > <- mesos_common.h -> > #include <a> > #include <b> > #include <c> > > <- xyz.cpp, which needs headers "b" and "d" -> > #include "mesos_common.h> > > #include <b> > #include <d> > > That way, the fact that "xyz.cpp" logically depends on <b> (but not > <a> or <c>) is not obscured (in other words, Mesos should continue to > compile if 'mesos_common.h' is replaced with an empty file).
That’s an interesting angle for a number of reasons. It would allow local reasoning about correct includes, and it also appears to help maintain support for ccache’d builds, https://ccache.samba.org/manual.html#_precompiled_headers For that one could include project headers such as `mesos_common.h` via a command line switch to the compiler invocation, without the need to make any changes to source files (possibly an interesting way to create some benchmarking POC of this proposal). Not changing source files for this would be valuable as it would keep build setup idiosyncrasies out of the source. If we wouldn’t change files we’d keep the possibility to make PCH use opt-in. Right now a ccache build of the Mesos source files and tests with warm ccache takes less than 50s on my 8 core machine (a substantial fraction of this time is spent in serializing (non-parallelizable) linking steps, and I’d bet there is also some ~10s overhead from Make stat’ing files and changing directories in there). Generating precompiled headers would throw in additional serializing step, and even if it really only would take 20s to generate a header as guestimated by Jeff, we would already be approaching a point of diminishing returns on platforms with ccache, even if we compiled every source file in no time. > Does anyone know whether the header guard in <b> _should_ make the repeated > inclusion of <b> relatively cheap? Not sure how much information gcc or clang would need to serialize from the PCH, but there is of course some form of multi-include optimization in both gcc and clang, see e.g., https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html Cheers, Benjamin
