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

[Ivan Kalvachev]

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:
>  > On Sat, Mar 1, 2008 at 1:28 AM, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
>
> > >  I'm not sure how you're reading it, but the problematic part is under
>  > >  #if 0 on the developer's box so the compiler really shouldn't give
>  > >  errors from it...
>  >
>  > There is no perfect system. You can find corner cases in each one.
>  >
>  > 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?

>  > one conditionally included headers you may spend recursively more time
>  > figuring out which one of them is the perpetrator. Mind you that the
>  > <unrelated.h> may include <foobar2.h> and so on and so on.... until it
>  > reaches <foo.h>
>  > This is if you ever bother with finding perpetrator, instead of
>  > including random selection of headers that seem to "fix" the problem.
>
>  There is nothing difficult about finding out which header is at fault in
>  cases of missing #includes. It's always the header which uses the
>  definition.

Huh? This is obvious from the compiler error.
What is not obvious is how to fix it.

>  > In your example it is immediately clear what file is missing and how
>  > to fix it. Even if there are more than one conditionally (not)
>  > included files, it is obvious that one of them is the perpetrator and
>  > not some other recursively included one.
>  >
>  > 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.

Am I wrong or I really do read same argument repeated for third time?

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

>  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.
You are saving time when writing code and you make it exponentially
harder to  debug it.

>  > In flat system, file is supposed to include only the headers it needs.
>  > Indeed, it is hard to figure out what header(s) are not needed anymore.
>  > Maybe Diego could come up with automated system for doing that.
>  >
>  > On the other side, recursive systems are also quite easy to have
>  > forgotten unneeded inclusions in them. There is no easy or/and
>  > automated way to figure out that you don't need given include anymore.
>
>  But it's still significantly easier to get right in a recursive system
>  where you only have to care about what the file itself needs than in a
>  flat system where you have to calculate the indirect dependencies caused
>  by other headers too.

Hum, I feel like you are repeating your previous argument.

>  > >  > When you have flat system, headers should not include other headers,
>  > >  > there should be no recursive dependencies at all.
>  > >
>  > >  What I mean by "recursive dependencies" above are headers required
>  > >  because of other headers. Those still exist whether they're actually
>  > >  included by the depending headers or not. Such a "flat" system just
>  > >  makes maintaining an accurate list of the header dependencies more
>  > >  difficult.
>  >
>  > Not that much.  I've heard that each recursion could be done with iteration.
>
>  It's possible to maintain an equally accurate list in a flat system.
>  Just a lot more work unless you have special tools for it.
>
>
>  > The biggest problem with recursive systems is when the order of
>  > inclusion matters. This is when we have conditional define based not
>  > on configure, but on the inclusion of other header. In this case you
>  > have to debug the order of inclusion and recursive follow all
>  > inclusions.
>  >
>  > I'm surprised that skilled coder as you haven't come up with such
>  > situation before (caused by other lousy coders of course). I'll assume
>  > that you think these kind of situations are rare and unavoidable, just
>  > like viruses under windows.
>
>  I think such situations are rare enough that they should not be the main
>  factor deciding which system to use. And it's not obvious that a flat
>  system would handle them any better. In a flat system each .c file can
>  satisfy the recursive dependencies of a header in a different fashion.
>  In a recursive system the header can better ensure a consistent
>  environment.

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

I'm sure you are not taking the flat system seriously because you have
never tried it. Try it for a few months and you will see that it is
much more comfortable.