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

[Robert Swain]

2008/8/1 Diego Biurrun <diego at biurrun.de>:
> 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.

To be fair, it took minimal time to fix.

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

I'd just like to point out that the AAC decoder isn't written by me.
I've just spent a couple of months or so cleaning it up.

Also, it's difficult to know what headers are required without seeing
the compilation errors. Usually compilation errors make it obvious
what is missing. Adding appropriate headers, recompiling, looking for
more errors due to missing headers and adding those doesn't really
take that long for one file.

Rob