> Why to stop the build instead of just giving a warning
> ("-Werror=declaration-after-statement" instead of
> "-Wdeclaration-after-statement") ?
> 
> Also, how is one UN*X extension developer supposed to deal with this
> error if he does not want to be compatible with VC ?
> 
> I think one of the following should be done:
> - change into a warning, and not make it an error
> - have a very clear message when 'gem install' fails with this error,
> and give a way to remove that error (thus removing temporarily the
> warn/error flag)
> 
> I think an error is fine when you are developing the gem (though there
> should be an easy way to ignore it), but it is not fine for a "gem
> install" user.

I like the spirit of this trunk commit; it helps ensure consistency of ruby's core codebase including the core extensions. It's an elegant way to help keep core buildable by both gcc and VC among other things.

However, I think the current implementation should be updated as it's a partial solution that's leaking into third-party code causing failures where failures previously didn't exist.

Specifically, update configure.in to inject a new $errorflags var (containing -Werror=declaration-after-statement) into Makefile's current $warnflags but filter it out when creating RbConfig::CONFIG['warnflags'] in lib/ruby/1.9.1/$(arch)/rbconfig.rb. This filtering allows a much finer and targeted control of configuring build environments among different platforms.

Essentially this means $errorflags would be used _only_ when building ruby and be used to enforce consistency on the core code without necessarily impacting downstream, third-party extensions.  As part of configure.in and friends, it's reasonably cross-platform and tweakable without creating _unexpected_ coupling between building ruby core and building ruby extensions.

Assuming this is a Good Idea, this should be made a feature request as the email title is too easy to skip over.

Thoughts?

Jon

---
http://jonforums.github.com/