>> Nor have you done the most basic of searches to discover the work by
>> many of the gem authors (Nokogiri, FFI, Thin, EventMachine, hitimes,
>> sqlite3, gherkin, do_sqlite3, ...) to support Windows users.
>
> That's because I'm not talking about gems, I'm talking about Ruby.

When you talk about Ruby, practically speaking, you implicitly talk 
about gems/extensions for desired/required functionality outside of 
what's in core+stdlib. That said, I don't know your use cases.


>> That's OK, but stop chumming this list.
>
> No, and you guys seriously need to stop that.  If my style offends you,
> blacklist me and be done with it.

You missed my point. I could care less about your style. Say what you 
want to say, how you want to say it, as most of the "cost" is yours.

But I do care when people state things as fact that just aren't so. For 
a list like this I think it's crucial to be clear about facts vs. 
speculation. It's OK to say things like "IIRC" or "(??)" don't you 
agree?


> As for fixing it, fixing it means not asking someone on windows to learn
> the gcc toolchain just to build an extension.  The express versions are
> free to download, asking the user to download an MS compiler or the gcc
> compiler should be a no brainer.

Now we're getting somewhere...specifics!  And I agree.

However, wrt the rubyinstaller installer .exe and .7z archives and build 
recipes I'm biased that this already is the case as we've abstracted 
much of the build toolchain.

For example, to build mri ruby from source you typically:

* clone the rubyinstaller github repo
* rake ruby19

and if you wan't to go a bit deeper (say build from your local ruby 
source with mods for vtune profiling and build with mingw 4.5.2) you may 
do something like:

* rake ruby19 local=c:\users\me\ruby-trunk vtune_build=1 
dkver=mingw-32-4.52

And as a user who want's to build a native gem, say rdiscount, you 
typically do something like:

* download the devkit
* install it via the dk.rb ruby script (can be tweaky, but that's 
another topic)
* gem install rdiscount [--platform=ruby]

Or if you want to build a gem that has external dependencies:

* gem install curb --platform=ruby -- --with-curl-lib="c:\curl\bin" 
--with-curl-include="c:\curl\include"

So many of the typical use cases are abstracted away already. That said, 
(a) there's areas that are a bit rough and could use some updates, and 
(b) the current recipes don't address your desire for the msft express 
toolchains or for the msft windows sdk.

As I said, I'm biased since I've been using and refining rubyinstaller 
for awhile. That said, we can always benefit from fresh eyes, fresh 
determination, and fresh horsepower.

Swing by our google group and weigh in with specifics. Hopefully you can 
tell by now that Luis (project lead) is always open for discussing how 
to make the rubyinstaller more useful for ruby windows users.


> Standardize on a version of the Express compilers and work with the
> rubygem maintainers to let gem authors offer different installs for
> Windows.  Suddenly, the user doesn't have to install a dev environment
> just to install a ruby gem, the complexity is pushed off to the gem
> maintainers, where it should be.

I agree with you if we were in a perfect world and had unlimited time 
and $$. Wouldn't it be great if a Window's user could type "gem install 
farfalle" and it automagically downloads a binary gem (1.8 or 1.9 
dependent upon what their using) with the correct runtime linkage for 
their system? And a *nix user downloads the gem and it builds for their 
system? Same for OSX, same for ___.

There are a lot of dependency details with this one.

Even though most people contribute in their spare time, without pay to 
fund their habits, a usable-but-not-perfect situation has evolved:

* gem authors on *nix can support their windows users via 
cross-compiling with mingw, taking advantage of Luis' rake-compiler 
helper.
* gem authors can build "fat" binary gems so a user doesn't have a 
1.8-only gem explode when they install it on their 1.9 system.
* native interop capabilities such as DL and FFI often help one 
integrate with windows libs.
* mri ruby and rubygems do windows-specific things to help
* rubyinstaller users can use the devkit to build and install native 
gems from source if there's not a correct binary gem available.

Perfect? No. Usable? Yes. Could it be improved? Of course.


> Windows is not Unix, stop pretending it is, and do things the Windows way when 
in Windows.

Another pov is that we've just found creative ways and creative tools to 
allow us to use MRI Ruby on Windows. It's a matter of pragmatism rather 
than pretending.

This is already well past tl;dr and likely best continued on the 
rubyinstaller group if you have specifics to contribute, but...

* as a Windows developer, what specifically are your "must haves" and 
"like to haves" for mri ruby on windows?
* what specifically keeps you from running mri ruby in a "production" 
environment?
* would your issues be the same from your user's (non-developers) pov?

Jon

-- 
Posted via http://www.ruby-forum.com/.