From: Francis Cianfrocca Date: 2006-07-17T02:10:01+09:00 Subject: Re: additional requirements for a Ruby env ------=_Part_84597_3676801.1153069796490 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I maintain several libraries that require extensions, and it's a complete pain in the neck to support. I can't imagine that the requirement for a locally-installed C compiler is anything but a barrier to adoption. I know some of you will come back and say "well, my extensions work just fine," but that's not my point. They're certainly no problem for someone who knows their way around a compiler, and I'm very grateful for the people who have sent me patches to get my stuff to work on obscure platforms. But how can you turn this into essentially a non-issue, so that it doesn't turn away the many people who don't have the patience to muck around with a compiled extension? This is obviously least problematical on Linux, but it can be a significant problem on production Linux servers and also OSX and Solaris machines, which often are built without compilers. Yes, I know they're easy to add but again, not my point. This should be a non-issue. And let's talk about Windows. You'd think Windows would be the easiest since there is one dominant compiler vendor (Microsoft) for the platform, but no. There are several different versions out there (VC6, VC7, VC2003 (no longer available but still out there), and VC2005), all with subtle incompatibilities. You have to be very careful with debugging builds because if you get the wrong library-flavor at runtime, your heap allocations don't work. Etc etc. Yes, you can download VC2005 express, but I really hate asking my users to do that! For those who would respond "well, if they want your library badly enough, they'll do it...," I have to say that I'm not happy to restrict my target audience to such a degree. I'd like to see a framework for building and testing binary releases of Ruby extensions on a range of different platforms (including Unix flavors). It might be possible to ship binary gems with several different binaries built into the gem, and the gem installer detect which is the most compatible one on any given target machine. There already is nice stuff in extconf for specifying required header and library dependencies. Can this be extended in a standard way so that a binary-gem builder can specify a range of platforms and have all the respective binaries included in the production gem? Maybe this would require some collaboration, with people making different build environments available to others, possibly through a secure mechanism sitting behind a Rails app? I'd be willing to make some different Unix and Solaris flavors available in a build tree so that the gems hosted at Rubyforge could be built on my hardware and the binaries loaded back to Rubyforge for final integration by rake. And hopefully others could contribute different platforms. I know I have taken the OP in a completely different direction, but I feel that the question he asked is only an important question because of issues that we could address in better ways. On 7/16/06, Alexandru Popescu wrote: > > Hi! > > I know there are Ruby libs outthere that are coming with C extensions. > To get them working you usually do a ruby setup.rb on your > environment. But, having C extensions, they will require that your ENV > has a few more things available (I assume a make, C/C++ compiler at > least). > > My environment is a Win XP machine, but I am not doing anything > related to C/C++ (and I haven't done anything for quite a long > time.... so my knowledge became quite rusty about). I would like to > hear from you, more experienced rubiest, what would be the lightest > env that would allow me to use such Ruby libs (I would like to hear > more options with some pros/cons, so that I can decide which one would > better fit). > > Many thanks in advance, > > ./alex > -- > .w( the_mindstorm )p. > > ------=_Part_84597_3676801.1153069796490--