On Tue, Sep 22, 2015 at 11:24 AM, Luca Barbato <[email protected]> wrote: > On 22/09/15 10:41, Vittorio Giovara wrote: >> On Mon, Sep 21, 2015 at 5:58 PM, Luca Barbato <[email protected]> wrote: >>> On 21/09/15 12:19, wm4 wrote: >>>> Ping? >>>> >>>> On Fri, 11 Sep 2015 13:02:49 +0200 >>>> Vittorio Giovara <[email protected]> wrote: >>>> >>>>> >>>>> the patch is very nice, but every time the deprecated variable is used >>>>> you should add FF_{DISABLE,ENABLE}_DEPRECATION_WARNINGS or you'll get >>>>> several deprecation warning messages. >>>> >>>> I don't really want to do this. It'd just be a big mess. Maybe it would >>>> make more sense to disable deprecation warnings entirely when compiling >>>> Libav? >>> >>> Probably makes sense to have the deprecation warnings off by default and >>> on on demand. >> >> no it does not, we already heard from downstream users it's difficult >> to notice deprecations with warnings, we would get twice as many >> complaints if there were no warnings at all. >> > > I mean when _building_ libav, the end-user shouldn't care about our own > deprecation warnings, isn't it?
if a deprecation warning comes up when building libav, it means some deprecated API is used within our codebase. If you think about it this would mean that we'd be using some stuff in our tree and mandate its removal in others, which in my opinion is ridiculous. in other words, if a deprecation warning comes up it means that the deprecation was not done correctly and end-users who are building libav and noticing a warning are welcome to submit a patch to fix that. -- Vittorio _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
