[FFmpeg-devel] Request for --disable-deprecated configure option

[Andreas Rheinhardt]

Kacper Michajlow:
> On Thu, 3 Apr 2025 at 11:39, Martin Storsjö <martin at martin.st> wrote:
>>
>> On Thu, 3 Apr 2025, Kacper Michajlow wrote:
>>
>>> Hello,
>>>
>>> It would be nice to have configure time ability to disable all
>>> `FF_API_*` for testing purposes.
>>>
>>> As we know not all code can be marked to emit Wdeprecated.
>>> Specifically #defines doesn't emit any warning and it's easy to miss
>>> such depreciation before it's actually removed.
>>>
>>> The breakage of course is not big, but the main issue is that the
>>> current release version of a ffmpeg user won't be compatible with
>>> ffmpeg after API bump, without any period for transition.
>>>
>>> --disable-deprecated could be used for testing and ensuring that
>>> (next) API bump goes smoothly. For both ffmpeg and its users.
>>
>> So essentially to configure a build to use the next major API version
>> before doing the actual bump?
>>
>> I've actually mentioned that we should do that (and that we should have a
>> FATE instance that continuously tests this, so that we know beforehand
>> that our planned next form of the APIs actually works), and I did try
>> making a PoC of it at some point, but unfortunately, I think I concluded
>> that it was a bit more messy than I had wanted, so I didn't continue
>> on it.
>>
>> See https://github.com/mstorsjo/ffmpeg/commit/next-abi for my PoC.
> 
> Yes, making the API version configurable would work. But as you
> noticed it gets a bit messy with all the conditionals.
> 
> I didn't think about it long, I wanted to discuss this first, but was
> thinking about a simple DISABLE_DEPRECATED which would be defined by
> configure and all `FF_API_*` would depend on that.
> 
> #define DISABLE_DEPRECATED 0
> #define FOO(c) (c) && !DISABLE_DEPRECATED
> 
> #define LIBAVUTIL_VERSION_MAJOR  60
> #define FF_API_MOD_UINTP2               FOO(LIBAVUTIL_VERSION_MAJOR < 61)
> #define FF_API_RISCV_FD_ZBA             FOO(LIBAVUTIL_VERSION_MAJOR < 61)
> ...
> 
> Also if someone wants to go fancy, the deprecated feature could be
> disabled individually, but I don't really see much use for that,
> except niche cases where you might still use deprecated things, but
> not all... but then just don't disable them.
> 

This was already possible until db932241ee16868475fe9ab4c958fcffd1829ecf.

- Andreas