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

[Michael Niedermayer]

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:
[...]
> > Some more concrete examples
> > avcodec.h uses int64_t, if it would #include inttypes.h it would be between
> > unuseable to a PITA in any environment that does not have inttypes.h.
> 
> It does already include inttypes.h indirectly through libavutil headers.

interresting, how much time did i took you to find that out? How much do you
think it might cause a average developer who debugs a problem related to it?


> 
> > libavcodec may be compiled with gcc + glibc in a gnu environment. but
> > it might be used in VC++ or another obscure environment that lacks these
> > headers.
> 
> If you create such workaround definitions it's not much more work to
> place them in a header named "inttypes.h".

as long as there is no inttypes.h already that maybe just misses half of the
things.


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


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


> 
> > The only reason why its not causing a problem is plain because its not
> > done, our headers luckily do in general not include all the headers they
> > somehow depend on.
> 
> I think they include more than you thought (I think pretty much
> everything ends up including the <inttypes.h> you talked about above for
> example). More like it doesn't cause much of a problem even though it IS
> done.

So it doesnt concern you that even i as maintainer of libav* has lost track of
which header includes which? Well i guess as long as "the right way" is
followed everyone will be happy ...


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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I count him braver who overcomes his desires than him who conquers his
enemies for the hardest victory is over self. -- Aristotle
-------------- 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/60c60152/attachment.pgp>