[FFmpeg-cvslog] r14484 - in trunk/libavcodec: audioconvert.c audioconvert.h
Michael Niedermayer
michaelni
Fri Aug 1 23:34:29 CEST 2008
On Fri, Aug 01, 2008 at 05:04:34PM +0100, M?ns Rullg?rd wrote:
>
> 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.
It seems we are very seriously misunderstanding each other.
The "rule" that every file always directly includes its dependancies has never
been followed, not even remotely.
There is a very large difference between somehow including all dependancies
in every file possibly indirectly through various headers and the "rule" that
all dependancies must be directly included.
This thread started because people complained about peter changing a direct
inclusion of avcodec.h to a indirect inclusion over audioconvert.h.
So i assumed that is what your "rule" is about. And this is what iam arguing
against. Such rule is insane and has never been followed in any project i know.
If you disagree iam curious which project is following such rule? The gnu
system headers very certainly not, they use various headers to include other
headers.
[...]
> > 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.
Could you please explain me, WHAT is better if all files redundantly
include their dependancies directly instead of for example audioconvert.c
including audioconvert.h that includes avcodec.h ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/5b80d962/attachment.pgp>
More information about the ffmpeg-cvslog
mailing list