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

[Måns Rullgård]

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.

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.

>> I wonder if suggesting FFBE_32 and av_bswap_32 everywhere has much of a
>> chance.
>
> i definitly want these to be available to the outside of libav so if we dont

Then we must rename them.

> find another solution then iam fine with these but it really would be nicer
> if a user app could use BE_32 instead of FFBE_32
> maybe some
>
> #ifdef AV_NO_PREFIXES
> #define BE_32 FFBE_32
> ...
> #endif
> in libavutil or similar could be used?

That would open a whole new can of worms.  We already know that Solaris
system headers #define BE_16 and friends.  It is a very generic name, so
we have no business imposing it on the world.

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.

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