[#8136] Confused exception handling in Continuation Context — "Robert Dober" <robert.dober@...>

Hi all

13 messages 2006/07/06

[#8248] One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...>

I just posted this to ruby-talk. But I would also like to discuss this

33 messages 2006/07/18
[#8264] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

From my experience using both tool chains on Windows (for the ruby-prof

[#8266] Re: One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...> 2006/07/19

Tim, I'm going to top reply since your post was so long. I'm interested in

[#8267] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

> Tim, I'm going to top reply since your post was so long. I'm interested in

[#8271] my sandboxing extension!! — why the lucky stiff <ruby-core@...>

I have (what feels like) very exciting news. I finally sat down to code up my

17 messages 2006/07/19

[#8430] Re: doc patch: weakref. — "Berger, Daniel" <Daniel.Berger@...>

> -----Original Message-----

19 messages 2006/07/28
[#8434] Re: doc patch: weakref. — Yukihiro Matsumoto <matz@...> 2006/07/29

Hi,

[#8436] Re: doc patch: weakref. — Daniel Berger <djberg96@...> 2006/07/29

Yukihiro Matsumoto wrote:

[#8437] Re: doc patch: weakref. — Mauricio Fernandez <mfp@...> 2006/07/29

On Sat, Jul 29, 2006 at 07:37:24PM +0900, Daniel Berger wrote:

[#8441] Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...>

I have the following code:

18 messages 2006/07/30
[#8442] Re: Inconsistency in scoping during module_eval? — nobu@... 2006/07/30

Hi,

[#8443] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/30

Why does this:

[#8445] Re: Inconsistency in scoping during module_eval? — Yukihiro Matsumoto <matz@...> 2006/07/30

Hi,

[#8454] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/31

So to clarify...

Re: One-Click Installer: MinGW? or VC2005?

From: Charlie Savage <cfis@...>
Date: 2006-07-19 01:36:02 UTC
List: ruby-core #8264
 From my experience using both tool chains on Windows (for the ruby-prof
extension and SWIG-based extensions for GEOS and GDAL).

* You can build Ruby extensions using MingW that run against Ruby built
with VC++.  I've done this with Ruby 1.8.2/1.8.4, various MingW releases
and VC++ 2003 and VC++ 2005.  This used to require changing a small bug
in ruby.h for Ruby 1.8.2, but that bug has been fixed with 1.8.4.  For
more info see
http://rubyforge.org/tracker/?func=detail&atid=1698&aid=2206&group_id=426.

* However, you cannot do this with MingW using VC++ built Ruby.

>   ruby extconf.rb
>   make
>   make install

The problem is that extconf is quite limited - it will assume you are
building your extension with the same compiler that built Ruby (VC++).
Python avoids this issue because disutils will recognize the compiler
being used (MingW, VC++) for the extension and provide the correct
command line parameters.

* If mkrf (http://glu.ttono.us/articles/2006/06/28/mkrf-0-1-0-released)
can work like Python distutils, then it will become simple to use MingW
to build extensions that work with VC++

* When compiling with MingW do not link against the ruby *.lib files.
Instead, just link directly against the DLL (msvcrt-ruby18.dll).  Its
faster (links much faster) and works better.

* So you need to manually compile your extension or create a makefile to
do it.  This actually turns out be the way GEOS and GDAL work - they
have autoconf based build systems so extconf.rb wouldn't fit in anyway.

* The advantage of MingW is that it avoids the unmanaged assemblies that
VC++8 uses, so its simpler to deal with (this is a good link about
manage assemblies -
http://www.grimes.demon.co.uk/workshops/fusWSThirteen.htm)

* VC++ has several large advantages on Windows.

First, it lets you debug your extensions while GDB does not support this
on Windows (or if it does, its never worked for me).

Second, it compiles much faster

Third, there is a lot more help available.

Forth, its quite easy to build Ruby extensions.

* Using MingW on Windows is a huge barrier to entry.  Gettting MingW
setup, along with msys, is a time consuming process that only
experienced *Nix developers will understand and be able to do.

* MingW on Windows is not very easy to use.  Its nice to think that you
can download an open source project, type ./configure, make, make
install and it will work.  Alas, it doesn't really work that way. There
are myriad of issues you run into.

First you'll need msys.  Then many projects have prequisites that you'll
have to download and compile.  In addition, you often times have to
change the CFLAGS and LDFLAGS to get successful compiles.  Linking is a
pain and requires hand-holding, and sometime just doesn't work.  Libtool
is really flakey on Windows.  For some projects, you'll have to need to
download/build/install the latest version of it.  You also need to get
autoconf/automake installed.  Many projects require bison - something
I've never been able to successfully compile on Windows. All in all - it
literally took me weeks to figure out how to get everything to work
together. The MingW/msys tool chain is quite complex on Windows, and
most people won't have the time or desire to put forth the effort to get
it to work.

My recommendation:

* Use VC++ 2005 and get Microsoft to tell us how to properly use 
unmanaged assemblies so that we can avoid dll hell

* Make sure that mkrf  supports building Ruby extensions
"out-of-the-box" on Windows using MingW if you have it installed.

I think this would be the best of both worlds - you support both tool
chains.  VC++ is the default one, but MingW should work fine for
building extensions.

Hope this helps - I'd be glad to share more of my experiences if its
helpful.

Charlie



Attachments (1)

smime.p7s (3.16 KB, application/x-pkcs7-signature)

In This Thread