On Tue, 18 Jul 2006, Curt H. wrote:
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
).