[FFmpeg-devel] [RFC] FF_API_*

Aurelien Jacobs aurel
Wed Nov 17 23:26:09 CET 2010


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

Aurel



More information about the ffmpeg-devel mailing list