[#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: Kaspar Schiess <eule@...>
Date: 2006-07-20 06:14:28 UTC
List: ruby-core #8312
Dear Curt, 

I have been a silent reader of your posts about the impe(n)ding decision 
you have to take for either the MS VC++ or the mingw toolchain.

Let's just sum up what has been said/can be said:

  - We need to go down either road *completely*. There seems to be no 
middle way. Or we could go down both roads, but would get stuck halfway 
(extension X being available for mswin builds, but not mingw builds, 
extension Y for mingw and not mswin, which to choose?). 

  - Mingw certainly has less documentation, but puts us in 'control' of 
availability of compilers. 

  - Microsoft seems to like the thought of you choosing MS VC++ publicly 
and assures you of their support. 

  - Ara Howard makes a good point by saying that unless a library (ruby 
extension or not) is explicitly constructed to build under MS VC++, it will 
require a lot of fiddling to get it built. The MS toolchain is just () very 
different from a unix toolchain () inadequate (choose what you prefer). I 
have myself chosen mingw over MS VC++ because of that. 

  - The same point can be made pro MS VC++ by saying that often, 
compilation of unix libs on mingw requires fiddling (and very unixish 
fiddling) too. I would wholly agree. 

  - The vision a lot of people have is to bring us closer to the 
installers-only universe that python has successfully created. Only that we 
are divided between the two compilers. We risk loosing momentum on a wrong 
decision. 

I really can't add to that; I think your decision is a hard one to make and 
there isn't a concise list of pros and cons to chose from. I (personally 
and as the maintainer for RMagick windows build) would be ready to invest 
my time in the following setups: 

  a. A 'pure' mingw build. This would be the best option for someone like 
me who likes using unix tools. 

  b. A compiler farm setup with either mingw or MSVC++. We should be able 
to deal out logins / distribute virtual disk images. This setup would have 
to be maintained. Everything needs to be compiled there / using that 
virtual machine. Requires close collaboration and some funding. 

  c. Going down both ways. Requires more manpower and may put us in 
either/or situations further along. RMagick would probably use mingw in 
this setup. Note that I currently know of no one that has succeded an 
RMagick build on a MS VC++ setup; but I am sure that this could be fixed 
given the proper time investment. 

I am grateful that you take the time to ask these questions. I hope I have 
advanced the discussion. 

best regards, 
Kaspar Schiess 

neotrivium.com - the swiss ruby shop


In This Thread