[FFmpeg-cvslog] r14484 - in trunk/libavcodec: audioconvert.c audioconvert.h

[Ivan Kalvachev]

On 8/2/08, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sat, Aug 02, 2008 at 12:13:13AM +0200, Diego Biurrun wrote:
>> On Fri, Aug 01, 2008 at 11:59:41PM +0200, Michael Niedermayer wrote:
>> > On Fri, Aug 01, 2008 at 07:19:54PM +0300, Uoti Urpala wrote:
>> > > On Fri, 2008-08-01 at 14:42 +0200, Michael Niedermayer wrote:
>> > > > On Fri, Aug 01, 2008 at 05:20:33AM +0300, Uoti Urpala wrote:
>> > > > > it's not realistic to keep
>> > > > > them in sync with indirect dependencies, at least not without
>> > > > > automated
>> > > > > tools that aren't used in practice.
>> > > >
>> > > > It worked in mplayer under arpi without a single issue i can
>> > > > remember.
>> > > >
>> > > > So all the pretty arguments stand in stark contrast to actual
>> > > > practice.
>> > >
>> > > MPlayer files included lots of unnecessary headers after dependencies
>> > > changed.
>> >
>> > Including all dependancies directly also causes many things to be
>> > included
>> > several times redundantly.
>>
>> No problem, we have multiple inclusion guards everywhere.
>
> The multple inclusion guards are in the header files not around
> the #includes
>
> file.c
> #include <stdint.h>
> #include "avcodec.h"
>
> avcodec.h
> #include <stdint.h>
> #include "avutil.h"
>
> avutil.h
> #include <stdint.h>
> #include "common.h"
>
> common.h
> #include <stdint.h>
>
> stdint.h
> #ifndef BLAH
> #define BLAH
> [lots of stuff]
> #endif
>
> will cause stdint.h to be parsed 4 times, the compiler has to, it has to
> find
> the correct #endif each time it hits stdint.h. There likely a more than 1
> #endif in it, it cant skip the #if /#else stuff in the middle


I do like the explicit inclusion system. I've argued before why I like it.
But indeed mans' argument is valid - it needs to be replicated in each .c file.
Then how about making it in 2 levels?

Each .c file includes only one header. This header contains all other
headers in predetermined order.
It may even speedup build if using precompiled headers. (gcc is
supposed to support them since v3.4)

Well, maybe instead of single header we may have 2 or 3. e.g.
system_includes, public_include and internal_includes.

After doing this nobody should be worried if and where
the headers he needs are included ...

I guess that common.h have been the first step in that direction,
but we never got to the second ;)