On Wed, 19 Jul 2006, Francis Cianfrocca wrote:

> There's one issue we may be finessing. What about installations (like
> production servers) where it's not acceptable to load a compiler at all? My
> gut says that this is an important issue going forward, especially as Ruby
> applications start getting used in enterprise environments. If you accept
> that, then the implication for this discussion is that extension writers
> really do need to start compiling and testing for a variety of possible
> Windows environments. Moreover, it means that binary-distro gems may need to
> be smart enough to carry more than one set of bits. We'll have this issue
> regardless of the choice you make between VC and MinGW, Curt.

exactly - this issue is orthogonal.

however, it would cetrainly simply things if the environment used to build
ruby could also be used to compile third party extensions.  take gsl for
example, i managed to compile it and the ruby extension via mingw - but i
__know__ the output from the compilers is subtly incompatible: for instance
isascii is a macro on one and an function in the other (forget which).  i
worked around this by hacking the source - and neither compiler is to blame
since ansi doesn't specify behaviour here - but it makes me queasy knowing
there are tiny differences between compiler abis.  my personal feeling is that
it's the plethora of binary installs available to windows that makes it so
dang unstable... but that's another issue.

in any case a mingw based ruby certainly doesn't preclude binary only installs
- indeed, rpms are binary and based on gnu tools.

regarding ruby stuff being 'easy' to install i'd say that opening up the world
of editing source and compiling it will certainly bring in patches and
contributions - and those may be steps towards making ruby extensions easier
to install be they binary or not.

cheers.


-a
-- 
suffering increases your inner strength.  also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama