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
unable to compile things like sqlite. what i mean by that it that it
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
on now : some will compile with mingw, some with vc++ 6, etc, etc, etc
whammo, we’ll be right back in the boat we’re in now - binary
people have to realize that, if ruby is compiled with a microsoft then
extension must also be compiled with vc++ and anything that compiles
as well! that’s an extremely steep hill to climb - for instance totally
packages like the gsl (note i said ansi, not posix!) do not compile
with microsoft compilers (in fact companies charge 600$ to do it!). in
addition, 90% of the neat stuff out there like postgres, sqlite,
all compile flawlessly on mingw and, therfore, allow people to compile
extensions against them. but here’s the rub: microsoft doesn’t provide
compiler toolchain which plays well with 90% of the popular
projects out there. it’s not the compiler that’s the toughest thing -
the lack of make, ld, ar, sh, etc that so many packages depend on that
microsoft based ruby so disappointing : it’s a ruby that cannot be
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
decent compiler toolchain to compile itself) then developers would be
develop binary extensions that speed ruby up and know that all ruby’s
compile them up themselves. think about what that might to for ruby’s
as it stand now making a binary installation that’s portable is simply
great a burden to expect many developers to put them selves through - we
this for free after all. why should tim have to figure out how to make
cross platform image magic installation when the build process of ruby
has already done so? why should the next developer have to re-invent
wheel already again? what i’m saying is that the standards of
sh/configure/gcc, etc solve the bane of every binary ruby extension
worst nightmare - portability - already. to not leverage this fact
massive violation of dry to say the least.
in addition, having a decent environment guaranteed for every ruby opens
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
incompatibilty problem - but simply towards a different one.
hopefully i will not start any flames, but that’s my 2 cts.