[FFmpeg-devel] [RFC] FF_API_*

[Michael Niedermayer]

On Wed, Nov 17, 2010 at 11:26:09PM +0100, Aurelien Jacobs wrote:
> On Wed, Nov 17, 2010 at 03:10:22PM +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > Currently some next major API/ABI changes are each protected under FF_API_*
> > This does make sense to allow us easily delaying  API changes that are
> > unfinished when we want to bump major.
> 
> > But it also adds a bit of maintaince
> > burden and work to remove all the no longer needed FF_API during a bump.
> 
> How so ?

there is the burden of adding  them for each change for example
its one thing if you convert existing code to it, another if everyone has to
think about one more thing and write the extra code.


> After a major bump, one will have to search for the dead code to
> manually remove it. Whether we search for LIBAV*_VERSION_MAJOR or for
> FF_API_* don't really make a big difference.

the big difference is that with 10 FF_API* you cant just search for FF_API
but must search for the 5 individual ones, one by one that actually where
enabled by the bump


> We could even have a script that grep the source to ensure that we don't
> have some orphaned #if FF_API_* that don't match a define FF_API_* from
> avformat.h or avcodec.h. After a bump, it would be enough to cleanup
> avformat.h and friends (trivial) and to run this script to point at code
> which needs to be cleaned.

this sounds a little like creating problems and then creating scripts to
solve them


> This script would have the additionnal advantage that it can be used to
> check source code sanity at any time. For example, if a work in progress
> API is finally removed because we decide it is useless, but that we
> forget some of the #ifdefed code. This script could point at it. If
> using LIBAV*_VERSION_MAJOR directly instead of FF_API_*, we wouldn't
> notice the dead code until we actually bump major...
> 
> > I thus propose to drop FF_API_* for changes that do work and only
> > protect things that are not yet finished under their own ifdef
> 
> If the maintenance budren after major bump is the only argument, I think
> that it is far from a compelling reason. Actually FF_API_* could even
> ease such maintenance tasks IMHO.
> Anyway, I still plan to try to make use of those FF_API_* for some kind
> of independent automated testing of future API at some point, so I would
> prefer to keep them (unless there is a really compelling reason to drop
> them).

what we need is testing (running full fate) with major bumped, the FF_API
used to seperate working code parts doesnt help there. For not yet working
FF_API is fine but thats a seperate thing and they cant be tested obviously


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

Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101118/8d2ef999/attachment.pgp>