Re: [PATCH 2/4] Do not include hw/boards.h if it's not really necessary

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> writes:

> On 16/04/2021 19.53, Philippe Mathieu-Daudé wrote:
>> Hi Thomas,
>> On 4/16/21 7:13 PM, Thomas Huth wrote:
>>> Stop including hw/boards.h in files that don't need it.
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>>   accel/tcg/tcg-accel-ops-icount.c | 1 -
>>>   accel/tcg/tcg-accel-ops-rr.c     | 1 -
>>>   accel/tcg/tcg-accel-ops.c        | 1 -
>>>   hw/acpi/cpu.c                    | 1 -
>>>   hw/acpi/memory_hotplug.c         | 1 -
>>>   hw/alpha/typhoon.c               | 1 -
>>>   hw/arm/aspeed.c                  | 1 -
>> It requires the macros declared by:
>> OBJECT_DECLARE_TYPE(MachineState, MachineClass, MACHINE)
>
> "hw/boards.h" is already included in include/hw/arm/aspeed.h, that's
> why it's working ... Hmm, do we have a policy whether a header should
> be included again in the .c file if it's already included by a .h
> file?

I'm not aware of a formal policy.

The most common "method" for dealing with #include is probably "when the
compiler demands declarations, throw #include at it until it shuts up".

This "method" only ever adds, never deletes.  It can easily lead to
including headers many times, and to including headers unnecessarily.

Including many times isn't much of a problem in practice.  A
sufficiently smart C compiler should be able to skip #include of a
"safe" header it has already seen, so redundant #include should not slow
down the build noticeably.  I prefer to avoid / delete obviously
duplicate inclusions anyway.

Including unnecessarily *is* a problem.  A massive one.  But it's not
what you asked about.

[...]