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

[Uoti Urpala]

On Mon, 2008-03-03 at 16:02 +0200, Ivan Kalvachev wrote:
> On Sat, Mar 1, 2008 at 7:20 PM, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > On Sat, 2008-03-01 at 17:30 +0200, Ivan Kalvachev wrote:
> >  > In Albeu's example it is not immediately obvious why exclusion of
> >  > <unreleated.h> causes error in <randomheader.h>. If you have more than
> >
> >  It is obvious. It's because randomheader.h fails to directly include
> >  another header it needs.
> 
> And how are you going to find that needed header?

Depends on the case. Why would it matter for this discussion? It's
equally easy/hard to find whether the includes are written in a
recursive or flat manner.

> >  > So the flat system always have linear time needed to find the bug,
> >  > where in recursive system you can have linear or bigger. (assuming you
> >  > need same time to check each header).
> >
> >  No, if you get a compile error caused by a simple missing #include it is
> >  straightforward to find out which file is at fault in both systems. In a
> >  recursive system it is the file which uses the undefined symbol, in a
> >  flat system it is the file which includes others.

> It looks like your solution for finding the missing header include is
> to brute force and grep through all headers in the project in order to
> find the definition.
> It is the slowest possible way to "fix" problem caused by missing
> header inclusion.

Your argument here makes no sense. There's no reason why the task of
finding out which header defines symbol X would be easier in a flat
system, and you haven't even tried to give a reason.

> I guess this task is so common that some IDE may implement it natively.
> 
> Please note, that you advice to workaround the bug without actually
> finding out why it triggered. This is fills directly in category of
> sloppy programming.

No. If symbol is used without being defined (because of a missing
#include) then you first need to find out which header can be included
to define it. This is no easier in a flat system. Then you add the
"#include" line. The only difference between the systems is which file
you add it to (and in both it's obvious which file that should be).
There's nothing "sloppier" about the recursive system.

> >  What differs is that in a recursive system it's easier to get includes
> >  right without trial and error. That means less work, better chances to
> >  avoid unnecessary includes (you can't catch THOSE by trial and error in
> >  a flat system), and better chances to avoid missing includes on
> >  configurations different from what you're testing with.
> 
> The tiny moment is that you are not getting it right. You are making
> the compiler try every combination at compile time.

"Try every combination"? As in the compiler trying to include a header
without its dependencies first, getting an error, but just continuing to
try other ways of including headers until it finds one that produces no
errors? Your compiler must be quite different...

> You are saving time when writing code and you make it exponentially
> harder to  debug it.

Yes you save time when writing code. I see no reason to believe your
"exponentially harder to debug" claim (for any interpretation of
"exponential").

> The flat system is not designed to fix developers mistakes. It is
> designed to make debugging and fixing easier.

It may be designed for whatever. The question is whether it's any good
in practice.