From: Curt Hibbs Date: 2006-07-19T01:27:12+09:00 Subject: Re: One-Click Installer: MinGW? or VC2005? ------=_Part_8320_17808963.1153240027572 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/18/06, ara.t.howard@noaa.gov wrote: > > On Wed, 19 Jul 2006, Curt Hibbs wrote: > > hi curt- > > > PS > > Below, Ara argues that a VC2005 version of Ruby would be unable > > to compile/use extensions built with the command sequence: > > not unable - but with a significant amount of work. > > > > > ruby extconf.rb > > make > > make install > > > > Isn't this incorrect? Wouldn't the sequence just become: > > > > ruby extconf.rb > > nmake > > nmake install > > > > If I'm wrong here, please let me know. > > let's take two common examples, sqlite and gsl. in both cases you are > going > to first need to compile the project itself, and then the ruby extension > written against it. > > sqlite : > > - get on google and search for how to build sqlite from source on > windows. > it doesn't come setup to do this. here are some example > instructions > > > http://initd.org/pub/software/pysqlite/doc/install-source-win32.html > > now, perhaps these are relevant and perhaps they're not. in > particular > note that the build is for a static library, meaning every ruby > (think > web server) process using sqlite will have the entire library in > memory. > note also that the build require gnu make (like everything else on > the > planet). most people will unlikely make it past this step. > > - get the ruby-sqlite bindings. run ruby extconf.rb. type > make. oops, > you installed ruby into a slightly different place than the person > who > build the one-click, who also used nmake. see, extconf.rb will > generate > a makefile using all the environment settings used at the time ruby > was > built, which will be one of the one-click installer maintainers' > machines , not the end user. so, in order for extconf.rb to > generate a > workable makefile the entire environment used to build ruby __must__ > exist on the end users platform. this may or may not be a hard > thing to > get right. of course, for something simple like sqlite the end user > may > be able hack things up - then again maybe not... > > - alternatively we can require that windows users get pre-built > binaries for > sqlite and ruby-sqlite. this places the burden of maintaintance on > the > very people who are already writing the free code! in addition, > it's not > that easy to provide binaries that will be compatible for all archs > and > all versions of windows. also, we cut out tens of thousands of > people who > might contribute patches to these projects since they get nothing > but a > box of bits. > > > gsl : > > - get on google and learn how to compile gsl for windows. note that > the > first four google hits have titles like 'ha ha ha' and 'nearly > impossible > to compile GSL for >> windows'. note that the fifth link is a > commercial > company selling a vc++ compiled gsl for $395. > > > http://www.google.com/search?num=100&hl=en&lr=&q=how+to+compile+gsl+for+windows&btnG=Search > > dispair. > > > > now, if one downloads mingw one gets a compile, make, and bunches of other > good stuff all at once. both sqlite and gsl can be compiled in minutes > using > > ./configure --prefix=/c/usr/local && make && make install > > same goes for ruby - compiles without a hitch. next we can download the > sqlite and gsl bindings and simply do > > ruby extconf.rb && make && make install > > done. > > > the crux of the issue isn't that vc++ is a bad compiler - it's obviously > not - > it's that many, many good ruby extensions are actually just hooks into 3rd > parth software which, itself, requires a 'minimal system' to compile: sh, > ld, > ar, gcc, etc. and that it's precisely this 'minimal system', not only the > compiler, which is 'remembered' by ruby during compile time and used to > create > rbconfig.rb, which is the foundation of mkmf.rb and extconf.rb. it's > interesting to run this command on a machine where ruby is installed: > > ruby -r yaml -r rbconfig -e' y Config::CONFIG ' > > do so and you'll see all sorts of stuff ruby considers important for > building > and installing things like > > ... > MAKEDIRS: mkdir -p > ... > AR: ar > ... > LN_S: ln -s > ... > RANLIB: ranlib > ... > LDSHARED: gcc -shared > ... > YACC: bison -y > ... > STRIP: strip -S -x > ... > NROFF: /usr/bin/nroff > ... > INSTALL_PROGRAM: /usr/bin/install -c > ... > > and this is only the tip of the iceberg - none of which include the > compiler > itself. ruby considers these programs essential for building itself and > it's > totally legit for any extension to make use of these values during > configure/build time and, in fact, many do. these programs may or may not > have to exist on end users machines in the same location (or at least in > PATH) > and the one-click builder's machine for them to be used. so, this is an > example 'minimal system' ruby might use and, by coincidence, is very > similar > the the environment provided by mingw. > > now, that's the for. here's the against: i can't swear that mingw is as > 'compatible' with microsoft as a microsoft produced compiler - common > sense > says it will not be. on the other hand, microsoft seems to have > compatibilty > issues even between it's own compilers so maybe this gut feeling is > wrong. in > any case i'm not expert here and would defer to illumination from one. > > one last thing - thanks so much for doing this work curt, community is far > better for it. > > cheers. Thanks for taking the time to post such a detailed account. Now that you mention it, I have encountered the very same problem myself with OpenSSL. I actually gave up trying to solve the compile problem when I found a pre-built binary for OpenSSL. Curt ------=_Part_8320_17808963.1153240027572--