Re: tidying up osdep.h

[Markus Armbruster <armbru@redhat.com>]

Peter Maydell <peter.maydell@linaro.org> writes:

> (cc'ing people related to the recent 'extern "C"' patches and also
> randomly Markus as somebody who's had opinions on header cleanups
> in the past...)
>
> osdep.h as it stands today is a mix of two things:
>  (1) it has the "must be included by everybody" items:
>    (a) config-host.h, poison.h, compiler.h
>    (b) things which must be done before any system header is included
>        (like defining __STDC_CONSTANT_MACROS or WIN32_LEAN_AND_MEAN)
>    (c) includes of system headers which we need to then fix up for
>        portability issues (eg redefining assert on mingw, defining
>        fallback versions of missing macros)
>  (2) it has declarations for a library of QEMU functions, some of which
>      typically wrap and abstract away OS specifics (like qemu_create(),
>      qemu_unlink()), and some of which seem to have just been dumped
>      in here for convenience (like qemu_hw_version())

It's such a convenient dumping ground :)

> Every file needs (1), which is why we mandate osdep.h as the first
> include; most files don't need a lot of the things in (2) (for instance
> qemu_hw_version() is used in just half a dozen .c files). Is it worth
> trying to split some of the type (2) items out into their own header files?
>
> I suspect that the advantages would be primarily just making osdep.h
> a bit clearer to read and less of an "attractive nuisance" for new
> additions; I imagine the bulk of the extra compilation time represented
> by osdep.h is going to be because it pulls in dozens of system
> headers, most of which are going to be required under heading (1).

I agree that keeping it focused on (1) would be cleaner, and that such a
cleanup probably won't speed up builds.  Regarding your question whether
the cleanup is worth the bother: I guess if somebody posts patches, it
is.