On 15 March 2016 at 09:29, Markus Armbruster <arm...@redhat.com> wrote: > = What to do about it = > > The immediately obvious thing to do is reduce "recompile the world" > headers that change frequently. I've started to do that.
This is obviously worthwhile. > Another one is attacking widely included bulky files (see "Top > scorers"). Some can simply be included less. Others need to be split, > in particular the generated tracers. But how important is this? Yes, the headers may make up a large %-of-total-source-lines, but how much extra actual compile time do they add? My off-the-top-of-my-head guess is that most of the time will be spent on optimization passes of actual code, and that things like structure definitions, typedefs, etc that you find in headers aren't going to make a major contribution. > Yet another one is reviewing the way we include system and GLib headers. We must include glib.h from osdep.h because it has compatibility fixups (in glib-compat.h) and we need to avoid the risk of a .c file including the system header directly without the fixups. > But our root problem is our undisciplined use of #include. Can we agree > on a sane set of rules? Here's my proposal: > > 1. Have a carefully curated header that's included everywhere first. We > got that already thanks to Peter: osdep.h. > > 2. Headers should normally include everything they need beyond osdep.h. > If exceptions are needed for some reason, they must be documented in > the header. If all that's needed from a header is typedefs, put > those into qemu/typedefs.h instead of including the header. > > 3. Cyclic inclusion is forbidden. I would be happy with these rules; we're a fair way away from them though. (Part of my aim with the osdep cleanup was to get to a point where it was easier to make header files self-contained without that implying every header needing a lot of system #includes.) thanks -- PMM
