> > 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.
> >

> 
> Jon, why not report this to Ruby-Core instead?
> 
> If the flag is going to have such impact on extensions and other gems,
> Core should hear this before that change hits another release.

Already started in the http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/33843 thread.  Not much uptake in discussion likely because the thread title is likely skippable ;)  Perhaps you or others would like to weigh in?

> More than "extending things to circumvent the change" in the form of
> patch or anything, better tell Core to revert that or make it default
> false with the optional configure flag.
>
> Sorry for the tone, couldn't resist that this needs to be deal on Core
> by Core and not discussed over this list.

In general, this is good feedback Luis. However, in this case, the issue has already been highlighted to core and I think it's premature to revert it or make it an optional default.  While I'm not yet decided, I fundamentally like the mod, but it needs to be enhanced as trunk mods often do.  On this FFI thread, I'm really interested in hearing Wayne's feedback since the FFI gem is an important cross platform capability.

At this stage I'm just trying to get some other PoV's on the dual build environment idea. If it adds value, the next step is a feature request.

Jon