On Fri, Sep 29, 2017 at 06:15:57PM +0200, Hendrik Leppkes wrote: > On Fri, Sep 29, 2017 at 2:40 PM, Clément Bœsch <u...@pkh.me> wrote: > > On Fri, Sep 29, 2017 at 11:38:42AM +0200, Hendrik Leppkes wrote: > >> On Fri, Sep 29, 2017 at 11:11 AM, Clément Bœsch <u...@pkh.me> wrote: > >> > From: Clément Bœsch <cboe...@gopro.com> > >> > > >> > Deprecated (aka removed) in OSX 10.11, and we have a replacement for it > >> > (VideoToolbox). > >> > --- > >> > Changes since RFC: rebase, ifdefery depreciation dance for the pix fmt, > >> > Changelog entry. > >> > > >> > >> vda.h is an installed header with public API in it, removing it > >> entirely would be an API and ABI break. > >> > > > > vda.h may be exposed unconditionally, but its associated object vda.o > > isn't. Since it depends on vda to be assembled, the vda stub itself > > doesn't seem to be present ever. So we're basically exposing a header for > > functions we can never link against. > > > > So should I somehow fix VDA while dropping it by providing a stub that was > > never present? > > > > vda is autodetected so a "naive" build would have it, so I would argue > the ABI of such a "naive" build should probably remain constant?
Just to be clear (sorry if I make you repeat yourself), we currently have the following: - Systems without VDA (that is, almost all of them) do not have access to either VDA or the stub: for them, we are exposing a header with FFmpeg symbols not accessible. - Systems with VDA have access to the VDA code (assuming it still build) What you suggest: - Both systems (with and without VDA) should now use the existing stub we currently never build so the ABI for systems with VDA will be kept. Is that correct? If so, this means we will start introducing a deprecated API stub for VDA on all systems. Or should I start exposing the stub only for VDA systems, meaning I'll need to keep the VDA detection in the configure? -- Clément B.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
