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

[Michael Niedermayer]

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:
> > > On Fri, 2008-08-01 at 03:27 +0200, Michael Niedermayer wrote:
> > > > On Thu, Jul 31, 2008 at 05:00:40PM -0400, The Wanderer wrote:
[...]
> > > > The rule of including headers in headers is a absolute pain for some use
> > > > cases to deal with. The advantage of this is purely "because its the right
> > > > way".
> > > 
> > > There was a thread about this on mplayer-dev-eng not too long ago that
> > > explained much more significant advantages. The main point is that it's
> > > realistic to keep the #include statements in a .c or .h file (mostly) in
> > > sync with what is needed _within that file_; 
> > 
> > really? then explain me why they are totally OUT of sync in libav*, since this
> > new idiotic system was adopted?
> 
> Out of sync how?

in the sense that it is easier to find a file that does not include its
dependancies directly than one that does.

example opt.h includes only libavutil/rational.h but uses int64_t


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


[...]
> > > > > cetera. If a header needs something then it should provide that thing,
> > > > > either by defining it directly or (more practically) by including
> > > > > another header which already defines it. A header which fails to do so
> > > > > is, IMO, broken.
> > > > 
> > > > Do you have a argument beyond "is broken" vs. "is the right way"?
> > > 
> > > See above.
> > 
> > above says that there was some thread on some mplayer ML, if thats all you
> > have thats not much.
> 
> I did also give specific reasons, but going through all the same things
> again a few months later is boring...

no problem


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080801/b08e75e6/attachment.pgp>