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

[Diego Biurrun]

On Wed, Feb 27, 2008 at 12:56:30AM +0100, Alban Bedel wrote:
> On Tue, 26 Feb 2008 23:25:41 +0100
> Diego Biurrun <diego at biurrun.de> wrote:
> 
> > On Tue, Feb 26, 2008 at 07:49:37PM +0100, Alban Bedel wrote:
> > > On Tue, 26 Feb 2008 14:25:01 +0100
> > > Guillaume Poirier <gpoirier at mplayerhq.hu> wrote:
> > > 
> > > > Ivan Kalvachev wrote:
> > > > > On Sun, Feb 24, 2008 at 3:23 PM, Diego Biurrun
> > > > > <diego at biurrun.de> wrote:
> > > > >> I've been having this lying around in my local tree for some
> > > > >> time.  The thread about OS X/Intel warnings reminded me to dig
> > > > >> this out again since it represents the all-inclusive general
> > > > >> solution.
> > > > >>
> > > > >>  So here are two patches, one to add the checkheaders target to
> > > > >>  mpcommon.mak and another proof-of-concept one that adds a
> > > > >> couple of the missing header files to assorted files (no, it's
> > > > >> not complete).  The idea is to have standalone headers in the
> > > > >> end that can be used without dependencies.
> > > > >>
> > > > >>  I'd like to commit this soon.
> > > > > 
> > > > > No
> > > > 
> > > > 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.
> > 
> > Headers should work standalone without the need to include them in
> > some magic sequence.  This policy is working quite well for the FFmpeg
> > project.
> 
> I agree to some extent, but putting tons of #include in .h files is not
> the solution. And including system headers like stdlib.h is just plain
> inaceptable.

Why would that be inacceptable?  It sure seems to work for FFmpeg.

> Many headers (including mines) are badly written and make use of typdef
> not defined in the same header. Get that sorted and you will cut at
> least half of the dependencies. Then what is left can be investigated,
> but I often see few resons to hide API dependencies from the reader.

This sounds like a good opportunity for cleanup to me...

Diego