Re: Did you succeed on Ruby-MinGW compilation?

> > We used it at the office (my company) and for our consulting services.
> > Since last year I'm struggling to get a working, faster environment
> > for Ruby on Windows.

> > Honestly I don't like this small struggling community of ruby for
> > windows users split again, so I'll love have you on the team and get a
> > faster product.
I can help out in a limited way


No problem, there are tools (free) that allow us create MSI
installers. WiX and WiXTool.


Nice.

Does ruby actually run faster in 64 bit modes?  I guess the good thing about it is that you can use more memory--like...you know...more than 4G or what not, so I guess being able to eventually compile in it would be nice. Do you think mingw will cut the bill for that?


> > - Modular design: currently as I commented to Curt, the installer is a
> > giant beast that lack testing and modularity -- even using the
> > rakefile -- it is a huge one too difficult to debug.
>
> There would probably be the natural way of dividing it
> to be 'main build' 'internal ext's' and
> 'gems' (which is, of course, nuts since gems
> is almost everything)

>I was talking about the core of the installer, since beside Ruby it
>needs the dependencies like OpenSSL, Zlib, Gettext, Iconv, readline,
>etc. available at install time.

So you want people to keep track of updates to these libraries and integrate them?  Not too much problem.  It seems like once you get ;a single build running (anywhere), then updating that build would be cake.

>In that way, we could "modularize"; or pluginize the installer and
>create, without too much hassle new installers for the different
>interpreters.

>;Simply the gem creation and building on Windows is one of the goals.

One option is to include a limited build with the distro (like just gcc.exe or what have you), and then gem creators can have it build still.

> > - Developer ecosystem friendliness: With the update to VC8 or MinGW,
> > the new Ruby distro will be more friendly to developers, so you will
> > need just a few instructions to get started, instead the whole problem
> > we are dealing right now.
>
> I still like the 'one click installer' idea, at
> least personally.  Then tell them to use
> gems (and how) and they are good to go

The One Click installer idea is still present, I meant provide better
documentation or support to Gem/Ruby developers with the new "distro".

>The survey will cover a "User/Developer" profile, so we could get a
>picture of the usage of Ruby on Windows.
 Asking for advice 'which do you prefer'; would be nice, too.

> 2) Have a working VC8, mingw, and VC6 (with extensions?) side by side. ; Err
> rather maybe just VC6 and a mingw build side by side so that people can
> download them and tell us which one they like more. ; Give them the choice to
> experiment and see if they like one more than another, then pursue that
> path. ; If no opinion then pick one

>There is a official build with VC6... and is the one that powers OCI currently.
>VC8 should be the option since is freely available (and VC6 no longer).
Once I get one working with all the libs I'd be happy to post it.

>; Mingw feels faster than VC6--that I can tell. ; It does. ; I like it

Of course, VC8 feels faster than VC6 too.
We should considerer the whoe spectrum and not just the speed of
things, stability is important.

>A lot of improvements are made to the ruby trunk regarding VC8
>compatibility, and MinGW, on the contrary, haven't improveed (haven';t
>seen commits about it) for the past year.

>;That is a important thing, and shouldn9;t be ignored, since Reinventing
>the wheel on a project like this is something huge.

Either way's good for me.

>Last, but no least, MinGW is more close to what vanilla-gcc is
>available under Linux (and similar to OSX too -- afaik), we shouldn9;t
>discard that knowledge neither...

>Is a difficult choice, but someone must take it

> Also it would be nice to run some really nice tests between all the versions
> to see what people are getting into

I don't know what you imply with "nice tests";. If you're just talking
about performance, even is important, stability came first.

Some tests that show file I/o and socket I/o would be nice.  Of course it MUST be stable--any real distro.

>(You already show me that RMagick is doing some weird things on MinGW).

Yeah we need to resolve those things before maybe...even mentioning it as a real alternative?  I can let you know when I finally get everything working.  The learning curve is somewhat bad here.

I don't understand exactly how this msys versus normal directory structure thing is actually supposed to work.  I think that the msys people envision you only using their tools from the console window or something? Huh? I just don't get it.

> If it were my personal choice I'd probably go for mingw, because then gem
> creators in Linux aren't "shooting in the dark" for the windows side of
> their gems.

On every gem or lib that I use I provided patches to ease the problems
with Windows platform, most due linux developers disregards things
like cross-platform, and code things for their own distro.

I sometimes have found code that couldn';t get it working on other
distro that wasn't the original used by the author';s gem.

> Of course, the real reason I'd suggest that is that I have an
> (almost) working build of mingw, and not a VC environment at all (I wanted
>; speed!).

Again, speed vs. stability. Getting the build environment for VC8
isn't too complicated either, but more complex than MinGW it is.

A note: VC8 is free, as I commented before.


The only drawback I see to mingw is that it probably ain't going to 64-bit anytime soon.  And we need to make sure it works.  Then again I've never even used it, so I have no point of reference.  I9;d say offer them both side-by-side for awhile (one for backwards compatibility), and see which one people like.  I think after they see that mingw is faster they'll all just use it...like automatically.