[MPlayer-dev-eng] [RFC] port 'make checkheaders' from FFmpeg

[Ivan Kalvachev]

On Wed, Feb 27, 2008 at 6:19 AM, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> On Wed, 2008-02-27 at 04:57 +0100, Alban Bedel wrote:
>  > On Wed, 27 Feb 2008 00:34:18 +0100
>  > Diego Biurrun <diego at biurrun.de> wrote:
>
> > > Why would that be inacceptable?  It sure seems to work for FFmpeg.
>  >
>  > Because a header have no business doing this kind of things. It
>  > completely hide which API the header is using. This just lead to an even
>  > complexer dependency tree which can bite you in even subtler ways, like
>  > this for ex:
>  >
>  > foo.h:
>  > #include <stdio.h>
>  > ....
>  >
>  > file.c:
>  > #if DEFINED_ON_THE_DEV_BOX
>  > #include "foo.h"
>  > #endif
>  > ....
>  > printf("No declaration for some ppl, but no warning for the dev");
>
>  And here's an example in the other direction:
>
>  foo.h:
>  <use math.h definitions without including math.h>
>
>  file.c:
>  <no math.h include>
>  #ifdef NOT_DEFINED_ON_THE_DEV_BOX
>  #include "foo.h"
>  #endif
>
>  Bugs are harder to avoid in the latter case. It's more realistic to
>  expect people to notice that file.c uses a definition but does not
>  include the header, than to notice that foo.h uses a definition but
>  file.c does not include the header.

This is exactly what we want.
We want to be harder to avoid bugs, so we can fix them easier.
You will get error (or at least warning), you will find the missing
header and you will know where to place it.
Case closed.


>  The basic issue is simple: it's much more realistic to manually maintain
>  an accurate list of what headers (and under what conditions) are
>  required BY THIS FILE, than to manually maintain an accurate list of

I've said before - This promotes sloppy coding. You can easily forget
one of the headers required by this file, and if it is somehow already
included  you may never notice. Let's say you forget to include
<stdlib.h> but you do include <stdio.h> that is supposed to include
the above one. Actually there are coders that won't bother putting
them both.

There is another issue I'd like to rice. Increasing the number of
includes slows down compilation as it makes the compiler parse same
headers again and again. I'm not so sure that gcc would keep track of
the open headers and won't reread them again and again (it is rather
trivial optimization). On lkml the noatime supporters are using as
example the update of access time of header files to illustrate major
bottleneck on filesystems. (the idea is that delaying the update would
save a lot of unnecessary writes).