One-Click Installer: MinGW? or VC2005?

I just posted this to ruby-talk. But I would also like to discuss this
separately on ruby-core where this is a higher level of expertise, and a lot
less noise.

Please read this and let me know what you think.

Thank you,
Curt

---------- Forwarded message ----------
From: Curt Hibbs <[e-mail]>
Date: Jul 18, 2006 10:22 AM
Subject: One-Click Installer: MinGW? or VC2005?
To: ruby-talk ML <[e-mail]>


 The One-Click Ruby Installer for Windows is at a cross-roads. The C++
compiler situation on Windows has become a complete mess because of subtle
incompatibilities and has, consequently, become a big headache for me and
extension writers.

I need to decide whether future versions of the One-Click Installer are
built with MinGW or MS VC2005 Express (both compilers are free). My bias has
been to go with VC2005 on the theory that the MS compiler will always be the
most compatible with Windows, itself.

However, Ara Howard makes a case (see below) for MinGW, so I want to have a
public discussion of the pros and cons of each path (please don't suggest
cygwin, it snot an option).

I'd like to ask that only those who have actual experience compiling
extensions for Ruby respond and that we keep the discussion to the pros and
cons of choosing MinGW or VC2005. I need to fully understand the
implications before choosing a path.

Thanks,
 Curt

PS
Below, Ara argues that a VC2005 version of Ruby would be unable
to compile/use extensions built with the command sequence:

   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.

 On 7/17/06, [e-mail] <[e-mail]> wrote:
>
> On Tue, 18 Jul 2006, Curt Hibbs 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
>