On Tue, Jan 3, 2012 at 4:37 PM, Diego Biurrun <[email protected]> wrote: > On Tue, Jan 03, 2012 at 04:19:11PM -0800, Jason Garrett-Glaser wrote: >> On Tue, Jan 3, 2012 at 3:58 PM, Diego Biurrun <[email protected]> wrote: >> > On Tue, Jan 03, 2012 at 03:35:19PM -0800, Jason Garrett-Glaser wrote: >> >> On Tue, Jan 3, 2012 at 3:32 PM, Diego Biurrun <[email protected]> wrote: >> >> > On Tue, Jan 03, 2012 at 03:26:30PM -0800, Jason Garrett-Glaser wrote: >> >> >> On Tue, Jan 3, 2012 at 2:29 PM, Diego Biurrun <[email protected]> wrote: >> >> >> > This fixes compilation failures related to START_TIMER/STOP_TIMER >> >> >> > macros and >> >> >> > -Werror=declaration-after-statement. START_TIMER declares variables >> >> >> > and thus >> >> >> > may not be placed after statements outside of a new block. >> >> >> >> >> >> START/STOP_TIMER are for development purposes only. There is >> >> >> absolutely no reason to make this sort of change for something that >> >> >> should never be enabled except during development. >> >> > >> >> > Except that one cannot use it for development right now, because >> >> > it will not compile? How can development code be exempt from >> >> > compilation requirements? >> >> >> >> -Werror=declaration-after-statement sounds like an extremely bad >> >> option to enable during development, since placing strict rules on >> >> variable declarations is just about the antithesis of hacking around >> >> wildly with code. START_TIMER in particular is dramatically more >> >> obnoxious to use with that option. >> > >> > You may well have a point here, but -Werror=declaration-after-statement >> > is now set by configure. So without the braces I add or a change in >> > the macros, compilation is currently failing. >> >> A better solution would be to revert the addition of such an insane >> default compilation flag. > > Feel free to go and flame for such a thing, but please let me add two > pairs of braces to fix compilation in the meantime.
Patch okay then. Jason _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
