[Ffmpeg-cvslog] r7238 - in trunk/libavutil: common.h internal.h

[Michael Niedermayer]

Hi

On Thu, Dec 07, 2006 at 05:39:19PM -0000, M?ns Rullg?rd wrote:
> 
> Michael Niedermayer said:
> > Hi
> >
> > On Thu, Dec 07, 2006 at 12:39:20PM +0100, Reimar D?ffinger wrote:
> >> Hello,
> >> On Thu, Dec 07, 2006 at 11:20:13AM -0000, M?ns Rullg?rd wrote:
> >> > Reimar D?ffinger said:
> >> > > So you suggest the better solution would have been to simply leave a
> >> > > 99,9% (i.e. except the always_inline) bswap.h in MPlayer instead of
> >> > > using the libavutil one?
> >> > > And does this mean that you do not agree that not being able to export
> >> > > any functions using always_inline is a bad thing?
> >> >
> >> > If you want to use currently not exported functionality, submit an RFE asking
> >> for
> >> > it to be officially exported.  Symbols whose name begin with av are official
> >> API,
> >> > nothing else is.
> >>
> >> I thought the intention was all of libavutil becoming "official API"
> >> in the long term.
> >> But since a ff_ prefix to always_inline was already considered too much
> >
> > ive no problem with a av_always_inline or similar for a externally vissible
> > one ...
> > also a av_inline would be a interresting option which would be shorter and
> > with which i would be perfectly fine even inside libav*
> 
> Fine, I'll create a prefixed macro instead.
> 
> I grepped the entire ffmpeg source, and the only uses of always_inline (and the
> other moved macros) were in our code, none in API headers.  For this reason I
> deemed it safe to move the macros to another place where they would not be
> visible to the outside, but still work exactly as before when building ffmpeg.
> I (or any other ffmpeg dev) can't reasonably be expected to keep track of which
> third-party apps abuse lav* internal symbols.  We broke VLC once by removing
> something they were illicitly using.  They happily fixed their code without
> making a fuss.  IMHO, MPlayer should not be receiving special treatment from
> this point of view, even if some ffmpeg devs also work on mplayer.

sure but i agree with reimar that completely hiding always_inline is not a
useable final solution, it IS usefull for applications ...


> 
> BTW, common.h has *no* listed maintainer.  I also thought the policy was that
> trivial changes didn't need approval, and I honestly think this qualifies as
> trivial.  Nobody would have objected, had it not been for mplayer being naughty
> and assuming things it shouldn't.

trivial changes which break nothing certainy dont, changes which break
something will lead to someone complaining trivial or not maintainer or not
...

if it would have broken a application which i dont use then sure i probably
wouldnt have complained that loudly but still (av_)(always_)inline should
be available to the outside


[...]

> We have an established convention of using an av prefix for the external API
> and ff_ prefix for internal symbols that need extern linkage.  Let's keep it
> that way.

yes of course

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

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali