------art_6151_32078198.1153234818072
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Ara, you make some very good points here. The One-Click Installer is at a
cross-roads here and I definitely want to choose the path carefully, after
considering all valid pros and cons.

I'm going to re-post this to ruby-talk as a new thread with the subject
"One-Click Installer: MinGW? or VC2005?" and explicit ask people to give
their take on solid pros and cons for each path.

Thanks,
Curt

On 7/17/06, ara.t.howard / noaa.gov <ara.t.howard / noaa.gov> 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
> --
> suffering increases your inner strength.  also, the wishing for suffering
> makes the suffering disappear.
> - h.h. the 14th dali lama
>
>

------art_6151_32078198.1153234818072--