[Qemu-devel] [RFC] How should QEMU code handle include statements (was: Re: [PATCH 0/5 v2] cpu: make a child of DeviceState)

[Stefan Weil <sw@weilnetz.de>]

Am 20.08.2012 13:47, schrieb Igor Mammedov:
> On Mon, 20 Aug 2012 06:52:51 +0200
> Stefan Weil<sw@weilnetz.de>  wrote:
>> I'd prefer if you could keep the following simple pattern:
>>
>> * Start includes in *.c files with config.h (optionally)
>>     and qemu-common.h.
> Can't agree with you on this. I'd say that every header should be be self
> sufficient, include other headers if it uses types from them and NOT depend on
> the position where it's included, it should provide all its own deps.
>> * Don't include standard include files which are already
>>     included in qemu-common.h
> Probably initially qemu-common.h was intended to simplify inclusion
> of standard headers and glue stuff in multi-os build environment. but it seems
> to be become misused. It includes now a lot of stuff that is not common to
> every file it's included in.
> Perhaps we should split out of it std includes and glue layer into something
> like std/host-common.h and case on case basis move out other type
> definitions that are not common into there appropriate places. Like with
> qemu_irq.


There are several possible strategies regarding include statements:

1. Each header file which represents some public interface must include
    any header file which it depends on, so applications which include
    xxx.h can rely on the fact that they won't need anything else to
    compile xxx.h.

    To minimize dependencies, this rule can be extended: each header
    file must not include unneeded header files.

    Usually header files in /usr/include are built according to these rules.

2. There is one header file (or a small set of header files) which includes
    a basic set of features which normal code needs. Any C code file starts
    by including this header file.

    Other header files can rely on the fact that the basic set of features
    are already available.

3. In a modification of (2), each header file can include the basic
    header file(s).

4. The status quo of QEMU is a wild mixture of those strategies.

IMHO, there should be a consensus about the strategy which is used
for QEMU code.

While I personally prefer (1) and used it for my first contributions,
QEMU introduced qemu-common.h. I had the impression that from then on
QEMU preferred strategy (2). Obviously not everybody shares that
impression.

Which strategy / rule do we want to use for QEMU code?

Regards,

Stefan Weil