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

[Ivan Kalvachev]

On Sat, Mar 1, 2008 at 1:28 AM, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> On Sat, 2008-03-01 at 00:49 +0200, Ivan Kalvachev wrote:
>  > On Wed, Feb 27, 2008 at 4:32 PM, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
>
> > >  There would be no error or warning on the developer's machine.
>  >
>  > It doesn't matter on whom machine it is, the bug would be triggered,
>  > found and fixed.
>
>  That's true of any "missing header" bug that occurs in practice, in any
>  model. Albeu's mail had an example where a missing include would go
>  unnoticed on a developer's machine if he had a different configuration.
>  In my reply I gave an example which showed that such problems can happen
>  just as well if headers don't include other headers, and are in fact
>  harder to spot in that case. Your comments on this have been incoherent.
>  I'm not sure what exactly you're trying to argue here.
>
>
>  > Actually after rereading your original statement I find it wrong. The
>  > compiler would output the error header and the error .c file where
>  > this header is used. You have all the info you need to fix the bug.
>
>  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
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.

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

>  > >  It's much easier still to forget a header required recursively by
>  > >  another header if that causes no warnings or errors on your machine. You
>  > >  didn't really address the main point of what I said: it is much more
>  > >  realistic to manually maintain an accurate list of headers for a file
>  > >  than for a file PLUS recursive dependencies.
>  >
>  > In the end you are having headers that include every other header. And
>
>  Only if you do it badly. And a "flat" system can lead to files that
>  include every header, and are much harder to clean up.

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.
Unless you know what all present includes do. This is usually true for
the system headers, but not so obvious for the application ones.
Automated bruteforce wont work because of high number of false
positives, tested include could easily be included by recursively
called header.

>  > if something goes wrong you don't have even the slightest idea in what
>  > order the headers have been included.
>
>  I don't know about you, but I wouldn't expect that to be a problem for
>  myself or most other developers.

I'm hearing that Microsoft are hiring skilled and self confident
people like you. You should at least try your luck there.

Unfortunately my last fix shows that other developers are not so
interested in solving complicated header inclusion problems.
Especially if they appear in obscure systems. The most common solution
is putting workarounds.

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

The key point here is that, it makes a list, instead of lossy mesh.
You have probably ignored my main argument for flat systems on the
original thread.
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.