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

[Uoti Urpala]

On Wed, 2008-02-27 at 13:35 +0200, Ivan Kalvachev wrote:
> On Wed, Feb 27, 2008 at 6:19 AM, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> >  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.

There would be no error or warning on the developer's machine.

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

It's much easier still to forget a header required recursively by
another header if that causes no warnings or errors on your machine. You
didn't really address the main point of what I said: it is much more
realistic to manually maintain an accurate list of headers for a file
than for a file PLUS recursive dependencies.

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

Can you give a reference to an lkml post that would be relevant to this
discussion? I know how leaving atime enabled can hurt performance
because of the extra writes to disk; however the atime updates done to a
header during the preprocessing of ONE file should stay in writeback
cache for at least that long, and so cause at most one write
independently of how many times the header is accessed. If you can give
no such reference I'll assume your atime talk was irrelevant.