# Extconf.rb spitting out SH Makefile on windows? **URL:** \ **Category:** ruby-talk\ **Created:** [3 March 2011 23:40 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021 "2011-03-03T23:40:59Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![Michael\_Reiland](https://avatars.discourse-cdn.com/v4/letter/m/977dab/32.png) [@Michael\_Reiland](https://rubytalk.org/u/Michael_Reiland)\ **Post date:** [3 March 2011 23:40 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/1 "2011-03-03T23:40:59Z")
Title says it all, I'm running ruby extconf.rb in a visual studio 2008 pro command prompt and the resulting Makefile is not for nmake. All I'm wanting is to create a single function that I can call into. I'm not willing to use SWIG, I see no reason to add more moving parts for something that should be so simple. Ultimately, if I could find documentation on how to set up the visual studio C++ environment so that I could compile the extension without the use extconf.rb, I would prefer that, but using extconf.rb is the next best thing. > **···** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). ---
**Author:** ![Eric\_Christopherson](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/eric_christopherson/32/1849_2.png) [@Eric\_Christopherson](https://rubytalk.org/u/Eric_Christopherson)\ **Post date:** [4 March 2011 06:10 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/2 "2011-03-04T06:10:20Z")
Since no one's chimed in yet, I thought I would just post to say you'd be best served installing the RubyInstaller DevKit, which includes gcc and GNU make. Others might know of ways to integrate Ruby with VS, but the conventional wisdom seems to be to use DevKit. > **···** > > On Thu, Mar 3, 2011 at 5:40 PM, Mr Eiland \ wrote: > > > Title says it all, I'm running ruby extconf.rb in a visual studio 2008 > > pro command prompt and the resulting Makefile is not for nmake. > > > > All I'm wanting is to create a single function that I can call into. > > I'm not willing to use SWIG, I see no reason to add more moving parts > > for something that should be so simple. > > > > Ultimately, if I could find documentation on how to set up the visual > > studio C++ environment so that I could compile the extension without the > > use extconf.rb, I would prefer that, but using extconf.rb is the next > > best thing. ---
**Author:** ![Luis\_Lavena1](https://avatars.discourse-cdn.com/v4/letter/l/f08c70/32.png) [@Luis\_Lavena1](https://rubytalk.org/u/Luis_Lavena1)\ **Post date:** [4 March 2011 23:40 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/3 "2011-03-04T23:40:43Z")
> Title says it all, I'm running ruby extconf.rb in a visual studio 2008 > pro command prompt and the resulting Makefile is not for nmake. What version of Ruby are you using? From what you say sounds like you're using RubyInstaller, which used GCC -- not Visual Studio -- as compiler toolchain. > All I'm wanting is to create a single function that I can call into. > I'm not willing to use SWIG, I see no reason to add more moving parts > for something that should be so simple. SWIG has nothing to do with compiler toolchain. > Ultimately, if I could find documentation on how to set up the visual > studio C++ environment so that I could compile the extension without the > use extconf.rb, I would prefer that, but using extconf.rb is the next > best thing. extconf.rb is required to create a Makefile compatible with Ruby. Please read README.EXT that is bundled in Ruby source code. Also, if you want Ruby with Visual Studio, build it or use the ones from GarbageCollect page: [http://www.garbagecollect.jp/ruby/mswin32/en/](http://www.garbagecollect.jp/ruby/mswin32/en/) Be aware to instal the missing binaries: [http://www.garbagecollect.jp/ruby/mswin32/en/documents/install.html](http://www.garbagecollect.jp/ruby/mswin32/en/documents/install.html) > **···** > > On Mar 3, 8:40 pm, Mr Eiland \ wrote: > > -- > Luis Lavena ---
**Author:** ![Michael\_Reiland](https://avatars.discourse-cdn.com/v4/letter/m/977dab/32.png) [@Michael\_Reiland](https://rubytalk.org/u/Michael_Reiland)\ **Post date:** [14 March 2011 18:17 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/4 "2011-03-14T18:17:20Z")
I ended up moving everything to the mingw toolchain, but I don't understand why you're saying it's impossible to use Visual Studio. At the end of the day the windows loader is the one doing the work, not the Ruby runtime. Unless you're telling me the dll being spit out by mingw isn't really a DLL? I would need a more in depth explanation before I would buy that Windows can load the appropriate DLL created by mingw, but not the equivalent DLL created by Visual Studio. We're not talking about compiler specific object files. > **···** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). ---
**Author:** ![Michael\_Reiland](https://avatars.discourse-cdn.com/v4/letter/m/977dab/32.png) [@Michael\_Reiland](https://rubytalk.org/u/Michael_Reiland)\ **Post date:** [15 March 2011 06:09 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/5 "2011-03-15T06:09:30Z")
It sounds to me like it has more to do with some of Ruby's design decisions, which is something I can believe. This will definitely be the last Ruby project I do on Windows, the Ruby team needs to work on their windows support. I'm a unix weenie so it's natural for me to use the mingw toolchain, but others aren't so fortunate. And no, I'm not willing to put forth my time to do it, I'll just be sure and avoid Ruby on windows from now on. Ruby is a beautiful language, but as far as I'm concerned it's hardly usable on Windows. > **···** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). ---
**Author:** ![Marvin\_GA\_lker](https://avatars.discourse-cdn.com/v4/letter/m/e95f7d/32.png) [@Marvin\_GA\_lker](https://rubytalk.org/u/Marvin_GA_lker)\ **Post date:** [4 March 2011 13:24 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/6 "2011-03-04T13:24:53Z")
I'd wonder if it was possible with Visual Studio anyway--All recent Rubies have been compiled with gcc (via MinGW/MSYS), and incorporating a C extension compiled with another compiler is not possible I think. The OP would have to compile Ruby with MSVC as well. Valete, Marvin > **···** > > Am 04.03.2011 07:10, schrieb Eric Christopherson: > > > On Thu, Mar 3, 2011 at 5:40 PM, Mr Eiland \ wrote: > > > > > Title says it all, I'm running ruby extconf.rb in a visual studio 2008 > > > pro command prompt and the resulting Makefile is not for nmake. > > > > > > All I'm wanting is to create a single function that I can call into. > > > I'm not willing to use SWIG, I see no reason to add more moving parts > > > for something that should be so simple. > > > > > > Ultimately, if I could find documentation on how to set up the visual > > > studio C++ environment so that I could compile the extension without the > > > use extconf.rb, I would prefer that, but using extconf.rb is the next > > > best thing. > > > > Since no one's chimed in yet, I thought I would just post to say you'd > > be best served installing the RubyInstaller DevKit, which includes gcc > > and GNU make. Others might know of ways to integrate Ruby with VS, but > > the conventional wisdom seems to be to use DevKit. ---
**Author:** ![Luis\_Lavena1](https://avatars.discourse-cdn.com/v4/letter/l/f08c70/32.png) [@Luis\_Lavena1](https://rubytalk.org/u/Luis_Lavena1)\ **Post date:** [14 March 2011 18:40 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/7 "2011-03-14T18:40:27Z")
> I ended up moving everything to the mingw toolchain, but I don't > understand why you're saying it's impossible to use Visual Studio. I'm saying that using Ruby build with MinGW is not possible to compile extensions with Visual Studio. > At the end of the day the windows loader is the one doing the work, not > the Ruby runtime. Unless you're telling me the dll being spit out by > mingw isn't really a DLL? I would need a more in depth explanation > before I would buy that Windows can load the appropriate DLL created by > mingw, but not the equivalent DLL created by Visual Studio. We're not > talking about compiler specific object files. Ruby 'mkmf' uses rbconfig, which is generated at compilation time of Ruby, and is going to use the toolchain defined when Ruby was compiled. Beyond altering rbconfig to detect and use Visual Studio, is a matter of CRT mismatch. This has been discussed in the list and the risk of memory allocation and free of it due Ruby's GC design can generate segfaults. And if you need better answers, you can google for them, described the problem above the big one, but there are others associated with compilation flags. > **···** > > On Mar 14, 3:17 pm, Mr Eiland \ wrote: > > -- > Luis Lavena ---
**Author:** ![Luis\_Lavena1](https://avatars.discourse-cdn.com/v4/letter/l/f08c70/32.png) [@Luis\_Lavena1](https://rubytalk.org/u/Luis_Lavena1)\ **Post date:** [15 March 2011 15:40 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/8 "2011-03-15T15:40:23Z")
> It sounds to me like it has more to do with some of Ruby's design > decisions, which is something I can believe. Yes and no, see what I've mentioned about CRT mismatch. > This will definitely be the last Ruby project I do on Windows, the Ruby > team needs to work on their windows support. I'm a unix weenie so it's > natural for me to use the mingw toolchain, but others aren't so > fortunate. And so the same for Visual Studio. > And no, I'm not willing to put forth my time to do it, I'll just be sure > and avoid Ruby on windows from now on. Ruby is a beautiful language, > but as far as I'm concerned it's hardly usable on Windows. Then stop complaining. If you're not willing to contribute back, then shut up. > **···** > > On Mar 15, 3:09 am, Mr Eiland \ wrote: > > -- > Luis Lavena ---
**Author:** ![Michael\_Reiland](https://avatars.discourse-cdn.com/v4/letter/m/977dab/32.png) [@Michael\_Reiland](https://rubytalk.org/u/Michael_Reiland)\ **Post date:** [17 March 2011 01:23 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/9 "2011-03-17T01:23:23Z")
Luis Lavena wrote in post #987573: > > It sounds to me like it has more to do with some of Ruby's design > > decisions, which is something I can believe. > > Yes and no, see what I've mentioned about CRT mismatch. Which is a technical challenge, not an insurmountable hurdle. See Python for an example. > > This will definitely be the last Ruby project I do on Windows, the Ruby > > team needs to work on their windows support. I'm a unix weenie so it's > > natural for me to use the mingw toolchain, but others aren't so > > fortunate. > > And so the same for Visual Studio. That's a shitty response. Windows dev's know Visual Studio,and the context of this entire discussion has been about building extensions in Windows, which makes your point facetious. > > And no, I'm not willing to put forth my time to do it, I'll just be sure > > and avoid Ruby on windows from now on. Ruby is a beautiful language, > > but as far as I'm concerned it's hardly usable on Windows. > > Then stop complaining. If you're not willing to contribute back, then > shut up. Roger that, send me a private email and I'll let you know how much it's going to cost you to influence my behavior. > **···** > > > On Mar 15, 3:09am, Mr Eiland \ wrote: > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Phil](https://avatars.discourse-cdn.com/v4/letter/p/e95f7d/32.png) [@Phil](https://rubytalk.org/u/Phil)\ **Post date:** [17 March 2011 10:00 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/10 "2011-03-17T10:00:14Z")
What Luis meant to say is that Ruby is open source. You are free to spend the time and effort necessary to fix the flaws you see. This is generally the case if a single person moves outside of a project's supported build chain (which is MinGW on Windows), a choice was made deliberately, since Visual Studio is only free in the Express versions, and that cannot be bundled with a third party download, as is necessary to support native extension building via RubyGems. The problem you have is a result of your own choice of tools, and you can't expect the community to fix problems that come about because of your specific situation. Not unless you are willing to provide incentives. Incentives that go beyond threatening to take your ball and never, ever again use Ruby on Windows. As far as threats go, it's a weak one, anyway: I'm not specially bothered that you won't use Ruby on Windows any more, just because it doesn't work with a tool not supported by the community. > **···** > > On Thu, Mar 17, 2011 at 2:23 AM, Mr Eiland \ wrote: > > > Roger that, send me a private email and I'll let you know how much it's > > going to cost you to influence my behavior. > > -- > Phillip Gawlowski > > Though the folk I have met, > (Ah, how soon!) they forget > When I've moved on to some other place, > There may be one or two, > When I've played and passed through, > Who'll remember my song or my face. ---
**Author:** ![Michael\_Reiland](https://avatars.discourse-cdn.com/v4/letter/m/977dab/32.png) [@Michael\_Reiland](https://rubytalk.org/u/Michael_Reiland)\ **Post date:** [17 March 2011 17:30 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/11 "2011-03-17T17:30:02Z")
Phillip Gawlowski wrote in post #987872: > > Roger that, send me a private email and I'll let you know how much it's > > going to cost you to influence my behavior. > > What Luis meant to say is that Ruby is open source. You are free to > spend the time and effort necessary to fix the flaws you see. This is > generally the case if a single person moves outside of a project's > supported build chain (which is MinGW on Windows), a choice was made > deliberately, since Visual Studio is only free in the Express > versions, and that cannot be bundled with a third party download, as > is necessary to support native extension building via RubyGems. mingw is not bundled with either Ruby Windows installer, or the rubygems installer, making your entire point moot. In order to build an extension via ruby gems, you have to: 1. install ruby 2. install ruby gems 3. install rubydevkit 4. execute a .bat or .ps1 file every single time you want to install or update a gem that needs to be compiled. So don't give me this bullshit about MS not allowing you to bundle 3rd party software, they don't bundle gcc either. > The problem you have is a result of your own choice of tools, and you > can't expect the community to fix problems that come about because of > your specific situation. Not unless you are willing to provide > incentives. Incentives that go beyond threatening to take your ball > and never, ever again use Ruby on Windows. As far as threats go, it's > a weak one, anyway: I'm not specially bothered that you won't use Ruby > on Windows any more, just because it doesn't work with a tool not > supported by the community. That's a nice story, but you missed the part where I explicitly stated I had moved everything over to the mingw toolchain, so take your strawmen and stuff them up your ass. I'm not using Ruby for Windows development because the windows support is shit, not because I have to use the mingw toolchain. That's a symptom, the problem is the community thinking it's acceptable to pretend Windows is Unix. Jackasses and fools on both sides of that argument. The jackasses who want to stay in unix land, even in windows, and the fools who think windows is the only OS out there. Next time, just acknowledge the point and state no one has any interest in fixing it instead of launching into the OSS party line. You'll stop misinterpreting statements of intention as threats. > **···** > > > On Thu, Mar 17, 2011 at 2:23 AM, Mr Eiland \ \> wrote: > > > -- > > Phillip Gawlowski > > > > Though the folk I have met, > > (Ah, how soon!) they forget > > When I've moved on to some other place, > > There may be one or two, > > When I've played and passed through, > > Who'll remember my song or my face. > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Luis\_Lavena1](https://avatars.discourse-cdn.com/v4/letter/l/f08c70/32.png) [@Luis\_Lavena1](https://rubytalk.org/u/Luis_Lavena1)\ **Post date:** [17 March 2011 18:35 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/12 "2011-03-17T18:35:22Z")
> mingw is not bundled with either Ruby Windows installer, or the rubygems > installer, making your entire point moot. In order to build an > extension > via ruby gems, you have to: > > 1. install ruby > 2. install ruby gems > 3. install rubydevkit > 4. execute a .bat or .ps1 file every single time you want to install or > update a gem that needs to be compiled. Incorrect. 1) Install RubyInstaller. RubyGems is already bundled 2) Download DevKit. Installation is a manual process for now, contributions are welcome to provide a real installer. 3) There is no step 3, gem install will trigger the gem compilation without polluting your normal environment. > So don't give me this bullshit about MS not allowing you to bundle 3rd > party software, they don't bundle gcc either. Dude, chill out, MS EULA forbids you to bundle Visual Studio with any tool. This is an old discussion about MinGW versus Visual Studio for Ruby for Windows, and you've reach to it 3 years later. You can still use Visual Studio, sure, go ahead download Ruby source code, download all dependencies and compile them with Visual Studio, and rejoice, be happy, go whatever you want. But don't come here to criticizes the work done by others. Windows != Visual Studio. There are other languages beyond C or C# and of course there are other compilers beyond Microsoft one. So all the offensive stuff you wrote is completely pointless. > Next time, just acknowledge the point and state no one has any interest > in fixing it instead of launching into the OSS party line. You'll stop > misinterpreting statements of intention as threats. Fixing? what is broken? Please, show it to me, wait, even better, send some patches, I will happily apply to Ruby itself. > **···** > > On Mar 17, 2:30 pm, Mr Eiland \ wrote: > > -- > Luis Lavena ---
**Author:** ![Jon1](https://avatars.discourse-cdn.com/v4/letter/j/47e85d/32.png) [@Jon1](https://rubytalk.org/u/Jon1)\ **Post date:** [17 March 2011 19:01 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/13 "2011-03-17T19:01:33Z")
> mingw is not bundled with either Ruby Windows installer, or the rubygems > installer, making your entire point moot. In order to build an > extension via ruby gems, you have to: > > 1. install ruby > 2. install ruby gems > 3. install rubydevkit > 4. execute a .bat or .ps1 file every single time you want to install or > update a gem that needs to be compiled. Get your facts right. 1. Installing Ruby via RubyInstaller also includes RubyGems. 2. Once you've installed the RubyInstaller DevKit you don't need to run a .bat or .ps1 file every time you need to install or update a native gem. The DevKit install process integrates with RubyGems by providing a pre-install hook that temporarily brings the DevKit onto your PATH. If you \_want\_ to use the DevKit toolchain outside of Ruby/RubyGems, by all means have at it by taking advantage of the .bat/.ps1 helper scripts. Glad you asked; there are very good reasons why the DevKit is not, nor should be, bundled by default with the RubyInstaller. However, if you do need/want the toolchain, it's fairly straightforward to integrate it. > I'm not using Ruby for Windows development because the windows support > is shit, not because I have to use the mingw toolchain. Your call, but what specifically do you mean by "...the windows support is shit...?" Seems from your posts you aren't happy with issues regarding your choice of toolchains, and you're not interested in understanding the tradeoffs made and solutions implemented for MRI Ruby on Windows users. And you've obviously not browsed through the Ruby/RubyGems source trees to see how much Windows specific support has been built in, or the number of bugfixes, etc. Any you likely haven't investigated JRuby's Windows support. 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 OK, but stop chumming this list. > That's a symptom, the problem is the community thinking it's > acceptable to pretend Windows is Unix. What the hell are you talking about? Who in the "community" is pretending Windows is Unix? > Next time, just acknowledge the point and state no one has any interest > in fixing it instead of launching into the OSS party line. Once again, what specifically is "..fixing it..." from your point of view? Jon > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Phil](https://avatars.discourse-cdn.com/v4/letter/p/e95f7d/32.png) [@Phil](https://rubytalk.org/u/Phil)\ **Post date:** [17 March 2011 19:46 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/14 "2011-03-17T19:46:23Z")
> mingw is not bundled with either Ruby Windows installer, or the rubygems > installer, making your entire point moot. In order to build an > extension > via ruby gems, you have to: > > 1. install ruby > 2. install ruby gems > 3. install rubydevkit > 4. execute a .bat or .ps1 file every single time you want to install or > update a gem that needs to be compiled. Step for is unnecessary, as has been pointed out. > So don't give me this bullshit about MS not allowing you to bundle 3rd > party software, they don't bundle gcc either. The Ruby DevKit \*does\* bundle a full compiler toolchain, not just what is required to have a compiler run (which would be ruby.h, and that'd be it, more or less). The DevKit download, however, cannot, and will not, include Visual C++ Express, since the EULA forbids redistribution by third parties. So, it's not possible to bundle VS in any way, shape, or form, and thus the community need for an NMake-compatible toolchain is pretty low. > That's a nice story, but you missed the part where I explicitly stated I > had moved everything over to the mingw toolchain, so take your strawmen > and stuff them up your ass. I refer you to your OP, where you said that Ruby's extconf.rb doesn't generate NMake compatible makefiles. Everything else follows from that. Including your outbursts. > I'm not using Ruby for Windows development because the windows support > is shit, not because I have to use the mingw toolchain. That's a > symptom, the problem is the community thinking it's acceptable to > pretend Windows is Unix. Jackasses and fools on both sides of that > argument. The jackasses who want to stay in unix land, even in windows, > and the fools who think windows is the only OS out there. That's why the RubyInstaller project created the DevKit. It makes, for all intents and purposes, the MinGW tools invisible to the average Ruby user. They are only noticeable if a gem blows up during compilation. Which is neither Ruby's nor Windows' fault, nor the fault of MinGW. BTW: Notice that Ruby mingw32 lacks any dependency on cygwin.dll. It's a fully native Ruby binary, not using any sort of compatibility layers to map \*NIX system calls to Windows equivalents. > Next time, just acknowledge the point and state no one has any interest > in fixing it instead of launching into the OSS party line. Fact is: OSS is volunteer driven. Fact is: OSS is "scratch your own itch" driven. Fact is: \*you\* want NMake compatible makefiles. Fact is: Unless you either do the patch yourself, or offer incentives for somebody else to provide a patch, you don't get to complain. You can file a bug, but otherwise you are left to the community's fancy and what is seen as a necessary feature (First: Get better Windows compatibility with Ruby). > You'll stop misinterpreting statements of intention as threats. Your tone is leaving very little to the imagination. That you aren't offering anything beyond "Ruby on Windows is shit", and "OSs party line", among curses, pushes you towards the "troll" end of things. Offer some suggestions or, better yet, patches to fix what you perceive as issues, and we are talking. But unless your bug reports become more verbose than "Windows support by Ruby is shit", nothing will be done. > **···** > > On Thu, Mar 17, 2011 at 6:30 PM, Mr Eiland \ wrote: > > -- > Phillip Gawlowski > > Though the folk I have met, > (Ah, how soon!) they forget > When I've moved on to some other place, > There may be one or two, > When I've played and passed through, > Who'll remember my song or my face. ---
**Author:** ![Michael\_Reiland](https://avatars.discourse-cdn.com/v4/letter/m/977dab/32.png) [@Michael\_Reiland](https://rubytalk.org/u/Michael_Reiland)\ **Post date:** [20 March 2011 05:49 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/15 "2011-03-20T05:49:13Z")
Phillip, until you stop with the strawmen, I'm going to ignore you from here on out. I know it makes you feel productive, but it's useless. You're explicitly ignoring later posts to attack what you perceive to be a slight on your romanticized view of OSS. > Incorrect. > > 1) Install RubyInstaller. RubyGems is already bundled > 2) Download DevKit. Installation is a manual process for now, > contributions are welcome to provide a real installer. > 3) There is no step 3, gem install will trigger the gem compilation > without polluting your normal environment. Fair enough, I installed in that order based upon everything I had read, but I don't claim to be an authority. In particular the documentation for DevKit left me with the impression that the environment had to be loaded up every time you wanted to use it. It's been long enough that I can't remember exactly where it was documented, so lets just call it a misunderstanding on my part. > Dude, chill out, MS EULA forbids you to bundle Visual Studio with any > tool. We're talking past each other. What I meant is the Ruby installer doesn't bundle gcc or Visual Studio, so the idea that it's built with gcc because Visual Studio doesn't allow 3rd party distribution is fallacious. I could \*maybe\* see your point if the installer came bundled with everything needed to build the gems that are compiled, but it doesn't. Once you've installed Ruby on Windows, you now get to go download another piece of software, so it becomes a matter of choice. DevKit, or \*Microsoft\* Visual C++ Express. > Windows != Visual Studio. There are other languages beyond C or C# and > of course there are other compilers beyond Microsoft one. Which is another shitty response. We're talking about C development on a Windows OS. The de facto standard is Visual Studio, in much the same way that there are other compilers on Unix, but the de facto standard is gcc, and you can't really talk yourself past that point. > This is an old discussion about MinGW versus Visual Studio for Ruby > for Windows, and you've reach to it 3 years later. Exactly, which is why I won't bother with Ruby on Windows anymore. It's unnecessarily difficult, and the community has already decided it isn't important enough to change that. That isn't a threat, it's me removing obstacles between my clients and their solutions. > But don't come here to criticizes the work done by others. I can, and I will. If that hurts your feelings in any way, grow a thicker skin. > 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. > 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. 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. 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. Windows is not Unix, stop pretending it is, and do things the Windows way when in Windows. update mkfm to SUPPORT WINDOWS, and that means more than simply using dlltools and then spitting out a Makefile. Piggyback off of CMake if you have to. [http://www.rubyinside.com/is-windows-a-first-class-platform-for-ruby-823.html](http://www.rubyinside.com/is-windows-a-first-class-platform-for-ruby-823.html) "Ruby development on Windows? The environment sucks (the language rocks though). Is that Windows fault? No. The community overall is very \*nix based, so development focuses on that environment, and very anti-Windows as is." This man nailed the problem, and the problem hasn't changed. The Windows support may have improved, but not enough to compete with other languages on Windows. And "use JRuby" is not a valid alternative. > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Luis\_Lavena1](https://avatars.discourse-cdn.com/v4/letter/l/f08c70/32.png) [@Luis\_Lavena1](https://rubytalk.org/u/Luis_Lavena1)\ **Post date:** [20 March 2011 14:35 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/16 "2011-03-20T14:35:24Z")
> \> 1) Install RubyInstaller. RubyGems is already bundled > \> 2) Download DevKit. Installation is a manual process for now, > \> contributions are welcome to provide a real installer. > \> 3) There is no step 3, gem install will trigger the gem compilation > \> without polluting your normal environment. > > Fair enough, I installed in that order based upon everything I had read, > but I don't claim to be an authority. In particular the documentation > for DevKit left me with the impression that the environment had to be > loaded up every time you wanted to use it. It's been long enough that I > can't remember exactly where it was documented, so lets just call it a > misunderstanding on my part. Please, wiki is open, introduce your edits to make it more easy to understand for newcomers. Let us know on our mailing list once you do it: [http://groups.google.com/group/rubyinstaller](http://groups.google.com/group/rubyinstaller) The page is here: > **[Development Kit](https://github.com/oneclick/rubyinstaller/wiki/Development-Kit)** > > RubyInstaller for Windows - Build recipes. Contribute to oneclick/rubyinstaller development by creating an account on GitHub. If something is not clear, we would like to correct it. > \> Dude, chill out, MS EULA forbids you to bundle Visual Studio with any > \> tool. > > We're talking past each other. > > What I meant is the Ruby installer doesn't bundle gcc or Visual Studio, > so the idea that it's built with gcc because Visual Studio doesn't allow > 3rd party distribution is fallacious. > > I could \*maybe\* see your point if the installer came bundled with > everything needed to build the gems that are compiled, but it doesn't. Not everybody needs a compiler bundled. Not every needs to install gems or compile extensions to use Ruby, why increase installers 20MB (GCC) or 2GB (Visual Studio + PSDK) for something you don't want? I believe I have stated this in the wiki in relation to this and other tools: > **[FAQ](https://github.com/oneclick/rubyinstaller/wiki/FAQ#bundled_short)** > > RubyInstaller for Windows - Build recipes. Contribute to oneclick/rubyinstaller development by creating an account on GitHub. [http://groups.google.com/group/rubyinstaller/msg/34dd829ebe0e4567](http://groups.google.com/group/rubyinstaller/msg/34dd829ebe0e4567) > Once you've installed Ruby on Windows, you now get to go download > another piece of software, so it becomes a matter of choice. DevKit, or > \*Microsoft\* Visual C++ Express. Over the past 5 years I've been actively working with Ruby for Windows and 4 years since I took over One-Click Installer, \*many\* have proposed make Ruby agnostic of the toolchain used to build extensions. But the truth is that nobody decided to do it, everybody complains and is a hard task. We are talking about changing an utterly non-OOP unstructured and commentless tool named 'mkmf'. Is a daunting task, specially since pretty much all extensions base on that tool to compile and introduce something like Pythons' distutil could introduce many many regressions. Instead of that, I decided to focus my efforts in reduce the complications while sticking to only one toolchain. Luckily for us Ruby is written in C, but if any of the parts of the language was written in C++ and exported, that will be impossible to deal with due GCC vs Visual Studio C++ different ABIs Again, the free/xfree malloc and mismatch of CRT you already know. Having all those drawbacks I think you will value what you can get now compared to previous Ruby for Windows situation which was the strict dependency on Visual C 6.0 You can search the web or read my my blog about that: [http://blog.mmediasys.com/](http://blog.mmediasys.com/) > \> Windows != Visual Studio. There are other languages beyond C or C# and > \> of course there are other compilers beyond Microsoft one. > > Which is another shitty response. We're talking about C development on > a Windows OS. The de facto standard is Visual Studio, in much the same > way that there are other compilers on Unix, but the de facto standard is > gcc, and you can't really talk yourself past that point. Again man, I believe I treated you with respect all this time. Calling shitty to responses you don't like is plainly aggressive and idiotic. Before Windows NT codebase there were different compilers for Windows, not just Visual Studio, seems you can't see beyond that point either. What you call "defacto" standard is what you want be your standard. Visual Studio Express not only complicates the compilation nature of Ruby and it's dependencies but also can't be automated to the point we use to deliver RubyInstaller. Please, I encourage you do the same thing we do with RubyInstaller project and how we build all the dependencies with Visual Studio and let me know. Excluding for a second that Visual Studio express lacks advance optimizations like PGO only found in paid version, which is a restrictive point for someone that works with Open Source Software want to contribute back but is not paid by it. Heck, over the past years there has been ZERO emails from Microsoft encouraging me use their tools, and pretty much everybody knows my email address. > \> This is an old discussion about MinGW versus Visual Studio for Ruby > \> for Windows, and you've reach to it 3 years later. > > Exactly, which is why I won't bother with Ruby on Windows anymore. It's > unnecessarily difficult, and the community has already decided it isn't > important enough to change that. That isn't a threat, it's me removing > obstacles between my clients and their solutions. To change that, work is required, clearly you're not interested in work on it. How you can get engagement from others if not even you are committed to it? If you want dinner served, go to a restaurant. I believe you're coming from a different mindset in relation to development, but Open Source works by actions, not by words. You can write down the most beautiful haiku but is pointless if you can provide a code that solves the problem. > \> But don't come here to criticizes the work done by others. > > I can, and I will. If that hurts your feelings in any way, grow a > thicker skin. You're not providing constructive criticism. Your words can't be backed by your work, and that is how things roll in Open Source. But again, this whole discussion is moot since clearly you've repeatedly said don't care about Ruby for Windows, so why bother answering? Seems you're the one can't move forward. > 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. If you consider it needs to be fixed, please, fix it and showed to us. > 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. Windows is not Unix, stop pretending > it is, and do things the Windows way when in Windows. MinGW is not Unix, is Minimalistic GNU for Windows and is GNU tools for Windows, is not emulating anything. It uses same libraries and similar headers than Visual Studio (ported to GCC syntax) > update mkfm to SUPPORT WINDOWS, and that means more than simply using > dlltools and then spitting out a Makefile. Piggyback off of CMake if > you have to. If by Windows you mean Visual Studio, see the mswin32 builds from garbagecollect: [http://www.garbagecollect.jp/ruby/mswin32/](http://www.garbagecollect.jp/ruby/mswin32/) Use that, use Visual Studio with it and be happy. As for Ruby and RubyInstaller: Patches are welcome. Everybody is a critic but no one is willing to put code where their mouth is. Show us -- with real code -- that all that we managed to achieve today is possible with Visual Studio Express, that it can be automated and that usage can be simplified. And I'm willing to take the chance of doing a RubyInstaller based on Visual Studio. And no, is not up to me to do it, you seem very interested in state that I'm wrong and you're right, so is up to you. As for the RubyInside article, ego on a side, see who is being quoted in it. > **···** > > On Mar 20, 2:49 am, Mr Eiland \ wrote: > > -- > Luis Lavena ---
**Author:** ![Jon1](https://avatars.discourse-cdn.com/v4/letter/j/47e85d/32.png) [@Jon1](https://rubytalk.org/u/Jon1)\ **Post date:** [20 March 2011 20:43 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/17 "2011-03-20T20:43:57Z")
> > 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/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Michael\_Reiland](https://avatars.discourse-cdn.com/v4/letter/m/977dab/32.png) [@Michael\_Reiland](https://rubytalk.org/u/Michael_Reiland)\ **Post date:** [22 March 2011 05:11 UTC](https://rubytalk.org/t/extconf-rb-spitting-out-sh-makefile-on-windows/62021/18 "2011-03-22T05:11:38Z")
> Over the past 5 years I've been actively working with Ruby for Windows > and 4 years since I took over One-Click Installer, \*many\* have > proposed make Ruby agnostic of the toolchain used to build extensions. > > But the truth is that nobody decided to do it, everybody complains and > is a hard task. > > We are talking about changing an utterly non-OOP unstructured and > commentless tool named 'mkmf'. > > Is a daunting task, specially since pretty much all extensions base on > that tool to compile and introduce something like Pythons' distutil > could introduce many many regressions. > > Instead of that, I decided to focus my efforts in reduce the > complications while sticking to only one toolchain. Which is fine, but I was asked what I thought should be changed. It isn't easy, and I'm not willing to put forth the effort, not when I can just use other tools. I love Ruby as a language, but when it starts getting between me and the solution, I stop using it. > What you call "defacto" standard is what you want be your standard. > Visual Studio Express not only complicates the compilation nature of > Ruby and it's dependencies but also can't be automated to the point we > use to deliver RubyInstaller. I call it de facto because most shops that develop for Windows are going to be using MS tools to do so. I called your response shitty because you act as if it's just as likely that a windows developer using C will be familiar with the gcc toolchain as they will with the MS toolchain, which is absolutely not true. Yes, there are other languages out there, but they are not under discussion, C is. That's also why I made my comment about jackasses and fools. When in Rome, do as the Romans do. When in Windows, do as the Windows devs do. You obviously have your reasons for doing things the way you have, but don't act as if it's reasonable to expect a Windows developer to be familiar with Unix tools. That's shitty. If you want to make the argument that they can learn, then do so, but that isn't the argument you made. For the rest of your response, please read back over what I said. I \*specifically\* stated that I would not be using Ruby on Windows for another project, and I did \*not\* give a call to action for anything. Phillip Gawlowski pigeon-holed my statements into the classic OSS strawman, and you're continuing in that vein. You specifically asked me what I thought was wrong, and I told you. It is unfair for you to treat that as a call to action when you \*asked\* for the input. I've already stated multiple times that my solution is to simply use other tools, I don't know how much more clear I can be. I really like Ruby, but that fondness no longer includes Windows. Jon, The great thing about the criticisms being mine is that I get to choose who is included in said criticism and I can tell you unequivocally that I included no gem authors. If you don't stop, I'm going to start thinking you dislike the gem authors. > \* 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? I am not a Windows developer, I have more experience with Unix, and I prefer Unix. I'm simply a developer who is flexible enough to comfortably develop in both environments. There are no must haves and nothing is preventing me from running it in a production environment. I haven't claimed either, so I'm confused as to why you would assume that was the case. I stated I wouldn't use Ruby on Windows in the future, I never stated it was unusable for me now. Not all of that is directly related to this particular discussion, but Ruby in Windows is subpar. This is not an isolated opinion. As for my users, I solved most of the issues by using an MSI installer. It feels like Windows to them, they're happy, and I get paid. > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C).