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

[Uoti Urpala]

On Tue, 2008-02-26 at 19:49 +0100, Alban Bedel wrote:
> On Tue, 26 Feb 2008 14:25:01 +0100
> Guillaume Poirier <gpoirier at mplayerhq.hu> wrote:
> > Mmmm.... looks like someone needs to grow up and become an adult....
> 
> Look like someone is still ignoring that some think that having all
> header deps resolved in the source is better. Ivan explaind several
> time why and I agree with him on this point.

But the current status in not really "having them resolved", nor is it
practical to maintain such status without listing the other headers
required for each header (either as functional #include statements or as
a separate list not used for compilation).

Current MPlayer sources usually include enough headers to avoid
compilation failures due to undefined identifiers. If they don't then
people add more by trial and error if nothing else. However many files
contain unnecessary includes. It's harder to know if an include is
unnecessary if it may be required by other header files in addition to
the current file itself. When the recursive dependencies of a header
change it's unlikely that the previous dependencies are removed from
files which include this header, and it's impossible to do this
automatically; there is no mechanical way to know whether the recursive
dependency can still be needed by another included header (at least
under some configuration possibly different from the current one).
There's also no easy way to be sure what other headers you need to
include if you want a particular one.

Given the above I think any really working and maintainable system which
flattens recursive dependencies would need to keep a per-header list of
dependencies and have tools to work on such lists. You'd still need that
per-file list of what (other) headers code stored in THIS file depends
on, not counting recursive dependencies. That would be the only directly
maintainable format for listing the dependencies. Flattened lists
containing recursive dependencies can only be generated from the
non-recursive lists, not maintained directly. MPlayer has no such system
for properly maintaining the flattened lists of dependencies, and I
consider making each header #include its dependencies a more practical
solution than trying to implement a better flattened system (which would
be more work for questionable benefit).