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

[Måns Rullgård]

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?

There hasn't been much of a problem, simply because the rule was followed
to a large degree prior to anyone calling it a rule.

> Hyphothetical claims have been given but these have never actually occured
> prior to this rule in ffmpeg.
> While now after the rule developers are being asked to follow it if they do
> not, that undoubtly costs extra time. Its not as if the code works better
> or worse if indirect inclusion is used compared to direct.

I have had the misfortune of working (in companies) on projects where the
rule was to *never* include header in other headers.  Believe me, it was
not fun.  By advocating the rule of

> But having to deal with the question "which headers do i need" is much
> easier based on a "the ones that contain the things in the error and
> warning messages" than "the ones listed in the standard for every function
> enum, struct, ... used in the current file"
>
> What iam saying is that the rule of direct inclusion is not practically
> doable plain because there is no automatic way that tells one what is
> missing when it is already available indirectly.

You raise a valid point, and it is something I indeed would like to see
a solution for.  Refusing to do the right thing even when you *do*
happen to know the requirements does not solve this problem.

> Considering this i think its unfair to pick people out and flame them
> for breaking that rule.

I agree, and don't flame people for breaking the rule by accident.

> Do you always know (without checking the specs)
> which header is needed for every function?

For functions I use frequently, yes.  If I'm unsure, I check the specs.

> I do not, so how should i or
> anyone else add the correct headers when all prototypes are already
> available indirectly so there are no warnings or anything at all that
> would hint at what is missing?

It shouldn't be too difficult to write a simple tool for finding the
dependencies.  A gcc option to do it would of course be nicer, but
I personally have no intention of touching gcc code.

-- 
M?ns Rullg?rd
mans at mansr.com