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

[Michael Niedermayer]

On Fri, Aug 01, 2008 at 11:54:32PM +0200, Diego Biurrun wrote:
> 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.

yes

but let me remind you that mans rule was all headers directly except what
common.h and internal.h provides. And these provide your missng headers
under #ifdef HAVE_AV_CONFIG_H
so while it would have worked under the rule you quote, that is not what mans
rule is.

Its not possible for people to follow such volatile and speaker
dependant rules.

So i suggest that you and mans first decide on what shiny rule you actually
argue for. It clearly doesnt seem to be matching each others currently.
Though both of you pretend it does.
And i have the weak feeling that you two unconciously adapt the rule from
mail to mail to make it work best.

Would it be possible that you could spell out the rule you think is a rule
so we all know beyond doubt if there are exceptions and if so which exactly.

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

There will always be a question for which you do not know the correct awnser.
-------------- 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/20080802/db717d0f/attachment.pgp>