Kacper Michajlow: > On Thu, 3 Apr 2025 at 11:39, Martin Storsjö <mar...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
