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