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.

Diego
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to