qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Our use of #include is undisciplined, and what to do ab


From: Markus Armbruster
Subject: Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it
Date: Tue, 15 Mar 2016 13:28:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On 15 March 2016 at 09:29, Markus Armbruster <address@hidden> 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.

I readily concede that we shouldn't speculate about compile time without
measurements.

We need to do something about the generated tracers, though.  Every time
you fiddle with a tracepoint, you get to recompile ~900 out of ~4000
files.  I suspect it's only 900 mostly because people avoid tracepoints
for that exact reason.  I certainly do.  If only the fiddled-with file
got recompiled, I'd happily use them for debugging, and when done post
any new tracepoints I found useful for others to enjoy.

>> 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.

I understand the problem.  Perhaps we can find a less heavy-handed
solution.  Not a priority for me right now.

>> 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.)

Okay, I can try to take us a few more steps in this direction.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]