Paolo Bonzini <pbonz...@redhat.com> writes: > On 15/01/19 13:28, Markus Armbruster wrote: >>> Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org> >>> --- >>> hw/arm/strongarm.h | 1 + >>> include/hw/arm/pxa.h | 1 + >>> include/hw/ssi/pl022.h | 1 + >>> include/hw/ssi/ssi.h | 1 + >>> include/qemu/typedefs.h | 1 - >>> 5 files changed, 4 insertions(+), 1 deletion(-) >> When typedefs.h changes, we recompile the world, but it pretty much only >> ever changes when new typedefs are added. Thus, *keeping* a typedef >> there is therefore pretty cheap. >> >> Nevertheless, we shouldn't keep typedefs there without a real reason. >> Being able to move one away without having to add any new #include >> directives is a strong sign for "no real reason". I like patches doing >> that. >> >> What I don't like is adding #include directives just so you can move >> typedefs out of typedefs.h: it slows down the build. Granted, the four > > (three - one added line is the typedef).
Correct. >> added by this patch are a drop in the bucket. The point I'm trying to >> make is typedefs.h's purpose: it's for avoiding #include directives. >> Circular ones in particular, but others, too. > > In this case, adding ssi.h inclusions to SSI controllers seems to be a > feature, not a bug. Adding #include can be a necessity. It can't be a feature any more than "slowing down your compiles" could be one :) I'm particularly wary of unnecessary #include in headers.
