No doubt, the compiler situation on Windows is a mess. There is some new
news, Austin Zeigler has been working with the Microsoft VC++ team (who was
dismayed to learn the Ruby on Windows was compiled with VC++ 6) to resolve
the issues with Ruby and VC2005.
I'll probably take over working with MS on this at some point. If we can get
this working, then VC2005 express would definitely be the preferred
solution. If that fails, then it will be MinGW.
why is that though? a VC2005 will still result in a broken ruby that will be
unable to compile things like sqlite. what i mean by that it that it will not
allow one to
- download sqlite
- compile it
- download sqlite-ruby
- compile that
which is to say that every single ruby extension that does
ruby extconf.rb && make && make install
will be unavialable to the windows ruby community.
if that is the case then people will immediately begin down the road they're
on now : some will compile with mingw, some with vc++ 6, etc, etc, etc and,
whammo, we'll be right back in the boat we're in now - binary
imcompatibility madness.
people have to realize that, if ruby is compiled with a microsoft then any
extension must also be compiled with vc++ and anything that compiles against
as well! that's an extremely steep hill to climb - for instance totally ansi
packages like the gsl (note i said ansi, not posix!) do not compile easily
with microsoft compilers (in fact companies charge 600$ to do it!). in
addition, 90% of the neat stuff out there like postgres, sqlite, open-ssl -
all compile flawlessly on mingw and, therfore, allow people to compile ruby
extensions against them. but here's the rub: microsoft doesn't provide and
compiler __toolchain__ which plays well with 90% of the popular open-source
projects out there. it's not the compiler that's the toughest thing - it's
the lack of make, ld, ar, sh, etc that so many packages depend on that makes a
microsoft based ruby so disappointing : it's a ruby that cannot be easily
extended -- one of the fundemental aspects of any modern language.
i think this is a greatly missed point. if it could be guaranteed that
__any__ ruby could compile binary extensins for itself (because it required a
decent compiler toolchain to compile itself) then developers would be freed to
develop binary extensions that speed ruby up and know that all ruby's could
compile them up themselves. think about what that might to for ruby's speed!
as it stand now making a binary installation that's portable is simply too
great a burden to expect many developers to put them selves through - we do
this for free after all. why should tim have to figure out how to make a
cross platform image magic installation when the build process of ruby itself
has already done so? why should the next developer have to re-invent the
wheel already again? what i'm saying is that the standards of
sh/configure/gcc, etc solve the bane of every binary ruby extension developers
worst nightmare - portability - __already__. to not leverage this fact is a
massive violation of dry to say the least.
in addition, having a decent environment guaranteed for every ruby opens many,
many possibilities - imagine if this worked for any ruby
system 'command >/dev/null 2>&1'
guess how many times that's come up on the list ;-)
in summary, a move towards any vc product will be a move not away from the abi
incompatibilty problem - but simply towards a different one.
hopefully i will not start any flames, but that's my 2 cts.
-a
