From: Jon Forums Date: 2011-03-21T05:43:57+09:00 Subject: Re: extconf.rb spitting out SH Makefile on windows? >> 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/.