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

[Diego Biurrun]

On Fri, Aug 01, 2008 at 11:39:27PM +0200, Michael Niedermayer wrote:
> On Fri, Aug 01, 2008 at 06:20:42PM +0200, Diego Biurrun wrote:
> > On Fri, Aug 01, 2008 at 05:01:48PM +0200, Michael Niedermayer wrote:
> > > On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
> > > > On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote:
> > > [...]
> > > > > Now please stop trolling, and get back to coding, which you do very well.
> > > > > Quite frankly though, I doubt you have the experience necessary to for
> > > > > an informed opinion on organisational matters like these.  That a certain
> > > > 
> > > > maybe. I do not claim to be an expert in header inclusion rules and do not
> > > > claim to have reviewed dozends of projects what they do and what problems
> > > > it causes. I just see how well it "works" here, and how little the claims
> > > > match reality.
> > > 
> > > Also, its interresting to note that the "all files must directly include their
> > > dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has
> > > existed MUCH longer than it, and it has never been a problem for _us_ so one
> > > has to ask what exactly did this rule fix that caused problems before?
> > 
> > I can give you one very concrete example that just bit me: I added ffaac
> > support to my local MPlayer tree by importing the SoC stuff into it.
> > Compilation of aac.c failed because it was missing math.h and string.h
> > headers.  But the first error message was about ENOMEM which puzzled me.
> > 
> > This did indeed take some time to fix, which could have been avoided if
> > Robert had #included all necessary headers from the start.
> 
> yes, but this has nothing to do with the discussion at hand.
> noone has suggested to NOT include the needed headers.
> 
> if robert forgot the headers no variant of the rule would have avoided
> that.

False.  It compiled fine in FFmpeg where it was getting the necessary
headers from somewhere, but not in MPlayer where the headers were not
provided.  I did not bother investigating in detail after the issue was
fixed but I suspect that HAVE_AV_CONFIG_H was #defined in one case, but
not the other.

Now if Robert had followed the rule of directly including all required
headers instead of relying on indirect inclusion, then this problem
would not have happened in the first place.

Diego