[#33640] [Ruby 1.9-Bug#4136][Open] Enumerable#reject should not inherit the receiver's instance variables — Hiro Asari <redmine@...>

Bug #4136: Enumerable#reject should not inherit the receiver's instance variables

10 messages 2010/12/08

[#33667] [Ruby 1.9-Bug#4149][Open] Documentation submission: syslog standard library — mathew murphy <redmine@...>

Bug #4149: Documentation submission: syslog standard library

11 messages 2010/12/10

[#33683] [feature:trunk] Enumerable#categorize — Tanaka Akira <akr@...>

Hi.

14 messages 2010/12/12
[#33684] Re: [feature:trunk] Enumerable#categorize — "Martin J. Dst" <duerst@...> 2010/12/12

[#33687] Towards a standardized AST for Ruby code — Magnus Holm <judofyr@...>

Hey folks,

23 messages 2010/12/12
[#33688] Re: Towards a standardized AST for Ruby code — Charles Oliver Nutter <headius@...> 2010/12/12

On Sun, Dec 12, 2010 at 9:55 AM, Magnus Holm <judofyr@gmail.com> wrote:

[#33689] Re: Towards a standardized AST for Ruby code — "Haase, Konstantin" <Konstantin.Haase@...> 2010/12/12

On Dec 12, 2010, at 17:46 , Charles Oliver Nutter wrote:

[#33763] [Ruby 1.9-Bug#4168][Open] WeakRef is unsafe to use in Ruby 1.9 — Brian Durand <redmine@...>

Bug #4168: WeakRef is unsafe to use in Ruby 1.9

43 messages 2010/12/17

[#33815] trunk warnflags build issue with curb 0.7.9? — Jon <jon.forums@...>

As this may turn out to be a 3rd party issue rather than a bug, I'd like some feedback.

11 messages 2010/12/22

[#33833] Ruby 1.9.2 is going to be released — "Yuki Sonoda (Yugui)" <yugui@...>

-----BEGIN PGP SIGNED MESSAGE-----

15 messages 2010/12/23

[#33846] [Ruby 1.9-Feature#4197][Open] Improvement of the benchmark library — Benoit Daloze <redmine@...>

Feature #4197: Improvement of the benchmark library

15 messages 2010/12/23

[#33910] [Ruby 1.9-Feature#4211][Open] Converting the Ruby and C API documentation to YARD syntax — Loren Segal <redmine@...>

Feature #4211: Converting the Ruby and C API documentation to YARD syntax

10 messages 2010/12/26

[#33923] [Ruby 1.9-Bug#4214][Open] Fiddle::WINDOWS == false on Windows — Jon Forums <redmine@...>

Bug #4214: Fiddle::WINDOWS == false on Windows

15 messages 2010/12/27

[ruby-core:33974] Re: trunk warnflags build issue with curb 0.7.9?

From: Jon <jon.forums@...>
Date: 2010-12-28 21:11:12 UTC
List: ruby-core #33974
> 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/

In This Thread