From: ara.t.howard@...
Date: 2006-07-19T01:12:55+09:00
Subject: Re: One-Click Installer: MinGW? or VC2005?

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.


-a
-- 
suffering increases your inner strength.  also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama