[ruby-core:22727] Moving ruby 1.9.1 forward on windows

Hi everyone,

In consultation with Luis and Roger, I'd like to discuss moving Ruby 
1.9.1 forward on Windows.  We have some concrete proposals that will 
require changes to the way Ruby is built on Windows as well as changes 
to rubygems.  First though, let me lay out our assumptions:

1.  The average windows user does not have a C compiler installed and 
isn't necessarily all that interested in getting one.

2.  Because of #1, extensions for windows should be packaged as binary 
gems (same as now)

3.  Ruby itself will likely be built by mingw32 (since the one click 
installer is headed that way), but msvc builds should also be expected 
and supported.

4.  Ruby extensions will be built with msvc (multiple versions), 
mingw+msys or cross-compiled.


Proposals
==========

Based on these assumptions, we propose the following changes (and will 
be happy to provide patches if the community can come to a consensus):


1.  Ruby library name

Proposal: The ruby runtime dll on Windows should *always* be named 
ruby19.dll.  Currently it includes the runtime library name 
(msvcrt-ruby19.dll for example).

Benefit: Having 1 runtime library name means gem developers only have to 
create 1 binary for windows, not 1 for msvc builds, and 1 for mingw 
builds.  This allows extension developers to use their toolchain of choice.


2.  rubygems platform

Proposal:  The ruby platform should not be differ for msvc and mingw (so 
no more mswin32-60 and mingw). We propose that the ruby gems platform 
for windows is always:

<architecture>-<os>-<ruby version>

Examples:

x86-mswin-19
x86_64-mswin-19

Benefit: This change will allow developers to create binary gems using 
their toolchain of choice (msvc, mingw/msys, cross-compile) and have it 
work against ruby built with either msvc or mings/msys.

Adding the ruby-version will allow rubygems to distinguish between 
binary gems built for ruby 1.8 versus 1.9 (which are clearly 
incompatible).  Perhaps rubygems already has a mechanism for this - I 
didn't see one in my research but could have missed it?


Mixing runtime libraries
========================

The most obvious criticism of this plan is that it will lead to mixing 
of microsoft runtime c libraries.  From my experience this works as long 
as extension developers follow the rules described here:

http://msdn.microsoft.com/en-us/library/ms235460(VS.80).aspx

To be more concrete, this boils down to two simple rules:

* If you call ALLOC or ALLOC_N, use xfree and not free
* Don't call sprintf or printf in an extension, instead use 
rb_f_sprintf/rb_vsprintf/rb_io_printf

If an extension violate these two rules then its obvious, a segmentation 
fault happens.  Thus these bugs are easy to find and easy to fix.

Since VC6 is thankfully no longer available, supporting msvc absolutely, 
positively requires mixing c runtime libraries and therefore extension 
writers must follow these two simple rules.  We don't view this as a 
particularly difficult burden, especially in light of the changes 
extension developers already frequently have to make for 1.9.1 
compatibility.


Conclusion
==========

* Fixing the ruby runtime library name is a 1 line patch which we'll be 
happy to provide
* Updating the rubygems platform is easy enough, but we assume deeper 
changes would have to be made for rubygems to download the correct gem 
binary.  We're happy to put together a patch if this seems like the 
right way forward.

Anyone have questions, objections, or better ideas?

Thanks,

Charlie



-- 
Charlie Savage
http://cfis.savagexi.com