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

[Alban Bedel]

On Wed, 27 Feb 2008 00:34:18 +0100
Diego Biurrun <diego at biurrun.de> wrote:

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

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");

Inside a given API, when you in fact have more or less a splited
header, or for "public" headers it can make sense. But referencing
headers from unrelated API just make following the real dependencies
harder. And it make adding senseless dependencies way too easy.

And honestly, in practice, how often do the dependencies of a well
written and widely used header change?

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

Yes, that's no small task, but I'm pretty confidant it would bring the
dependencies down to a much more manageable level.

	Albeu