[Rubyinstaller-devel] Did you succeed on Ruby-MinGW compilation?

[Roger Pack]

For some reason the mingw gcc is having trouble with finding headers and
libs.  It is reasonably annoying :)

$ cat test.c
#include <zlib.h>

Melissa at MELISSA-PACK /c/take3/ruby/ext/zlib
$ gcc test.c
test.c:1:18: zlib.h: No such file or directory

Melissa at MELISSA-PACK /c/take3/ruby/ext/zlib
$ ls /usr/local/include
GraphicsMagick iconv.h libcharset.h localcharset.h zconf.h zlib.h

It's there! I see it!

Anyway gcc is loading its own directories--I think the problem is that I
unzip things within the 'msys' framework, when in reality I should unzip
them all within the mingw subdirectory.  Man that is so retarded!


I am also having some serious difficulty getting openssl to compile, still.
 I honestly don't know how to do it!

On yours does it actually compile anything after it says "compiling zlib" or
what not?



> > 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.


Amen to that.


> > 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.exeor 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 shouldn'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 shouldn'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.  I'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.


Good luck to all of us!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20071022/2e4c2c26/attachment.html