On Fri, Sep 29, 2017 at 8:39 PM, Clément Bœsch <u...@pkh.me> wrote: > On Fri, Sep 29, 2017 at 08:12:14PM +0200, Hendrik Leppkes wrote: > [...] >> > 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? >> > >> >> Obivously including the stub everywhere is much easier and far saner, >> does it really harm to do that? >> > > It's just a bit weird to actually introduce deprecated symbols that > weren't there in the first place. >
Since at least BBB was slightly confused by my comments, just to clarfiy: I don't really care how its done, but the ABI should remain intact. If I do a simple build on mac today with ./configure && make and it includes vda symbols, then so it should afterwards, even if they are non-functional. How thats done, I don't mind. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel