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

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

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

OK, but it hasn't previously been officially provided by lavu.

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

I didn't think it would break anything, since it didn't touch anything
that other apps should have been using in the first place.

> if it would have broken a application which i dont use then sure i probably
> wouldnt have complained that loudly

Of course not.  You wouldn't have noticed it at all...

> but still (av_)(always_)inline should be available to the outside

Alright, I'll make it so.

-- 
M?ns Rullg?rd
mru at inprovide.com