On 9/29/2017 6:56 PM, Hendrik Leppkes wrote: > 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.
Then IMO we should wait until the major bump (Which is not too far away). Leaving a stub object for the symbols and configure clutter should be avoided. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
