I think it's fine to enforce code consistency for MRI core and it's included extensions, but agree with you on breaking third party code. I can't yet see how this mod enhances code quality. Extension API's already exist for third parties to code to. IMO, a build flag is not an API.

It will be interesting to see how many support issues start popping up as this mod affects mainstream *nix-based builds. I also wonder if/how http://rice.rubyforge.org/ users will impacted.  At least the mod's on trunk rather than a release branch :)

How would you feel about having "pre-install" and "post-install" build environments in which things like -Werror=declaration-after-statement only live in pre-install (building ruby proper) but are filtered out of RbConfig::CONFIG used by extensions? 

Time permitting, I'd like to mock up something for core's review that uses a new $errorflags var that is injected into $warnflags in ruby's Makefile, but is filtered out when generating lib/ruby/1.9.1/$(arch)/rbconfig.rb so that extensions have a less strict RbConfig::CONFIG['warnflags']. It would give more flexibility to tighten up core code checks using gcc's available features while being more precise in constraining third party code. Good or bad idea from your PoV?

> My opinion is whilst it is nice to be anal about code quality,
> breaking _third party_ code that used to build fine, is
> counter-productive, and going to cause both gem authors and end users
> a large amount of pain - and is therefore wrong.
> 
> Since it seems to be the only instance of that, it'd probably be just
> as easy to fix it.  O add -Wno-declaration-after-statement to cflags
> 
> 
> 
> On 28 December 2010 01:11, Jon <jon.forums@gmail.com> wrote:

> > Using MRI 1.9.2-p136 I successfully install the 1.0.3 binary gem via
> >
> > C:\Users\Jon>gem update ffi
> > Updating installed gems
> > Updating ffi
> > Successfully installed ffi-1.0.3-x86-mingw32
> > Gems updated: ffi
> >
> >
> > But when I try to update using MRI 1.9.3dev (trunk@30404) I get the following failure. I don't have time to investigate further, but there appears to be two issues: (1) FFI fails to install a binary mingw32 gem when run on MRI 1.9.3dev, and (2) recent trunk configure.in mods (-Werror=declaration-after-statement) are leaking into, and breaking, the FFI gem build similar to the 0.7.9 curb gem breakage.
> >
> > I've commented on (2) in this ruby-core thread http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/33843  While I think the trunk mod is great for enforcing MRI core code consistency, I think it's a bad idea to leak this new build constraint into every native gem out there.  Whether you agree or disagree with my view, I think ruby-core needs more feedback on the topic before the mod gets backported to ruby_1_9_2.
> >
> > Or, if you agree with core, mod the FFI code to be strictly compliant with ISO C90 :)
> >
> >
> > C:\Users\Jon>gem update ffi
> > Updating installed gems
> > Updating ffi
> > Temporarily enhancing PATH to include DevKit...
> > Building native extensions.  This could take a while...
> > ERROR:  Error installing ffi:
> >        ERROR: Failed to build gem native extension.
> >
> > C:/ruby19trunk/bin/ruby.exe extconf.rb
> > checking for rb_thread_blocking_region()... yes
> > ...
> > compiling Function.c
> > compiling FunctionInfo.c
> > FunctionInfo.c: In function 'fntype_initialize':
> > FunctionInfo.c:161:5: error: ISO C90 forbids mixed declarations and code
> >
> >
> > # ext/ffi_c/FunctionInfo.c:161
> > #if defined(_WIN32) || defined(__WIN32__)
> >    VALUE rbConventionStr = rb_funcall2(rbConvention, rb_intern("to_s"), 0, NULL);
> >