On Tue, 27 Jun 2006, Austin Ziegler wrote:

> On 6/26/06, Bill Kelly <billk / cts.com> wrote:
>> I'm not sure if this is the sort of information you're looking
>> for, but I've run into the occasional extension, and/or library
>> upon which an extension relies, that essentially requires
>> mingw/msys to build.
>
> Not specifically. However, part of what I really want to try to get
> the MS team to help us out with is a situation wereh I have
> ImageMagick built with MSYS, RMagick built with Visual Studio 2005 (cl
> 14) and Ruby built with VC++6 -- and it all Just Works.
>
> Right now, apparently, this is a nightmare and there's "no way in
> hell" that it would work. They're interested in helping us; I'm not
> about to turn down the help of the compiler writers. Which is why I
> need more information.

imho microsoft would be __extremely__ hard pressed to deliver here: the issue
isn't so much with the compiler itself, it's that any ruby built with ms
compilers is going to produce a badly crippled ruby.  specifically i mean that
a ruby that cannot

   ruby extconf && make && make install

is broken.  the point here is that it's not so much the compilers themselves
which are the issue, but the compiler toolchain, including a minimal set of
tools to bootstrap a configuration from.  it's the lack of tools like make,
yacc, sh, etc that make it impossible to do

   cd gsl-1.8/
   ./configure --prefix=/usr/local && make && sudo make install

   export LD_RUN_PATH=/usr/local/lib/
   export LD_LIBRARY_PATH=/usr/local/lib/

   cd ruby-gsl-1.8/
   ruby extconf.rb && make && sudo make install

eg.  a 'usable' ruby compiler should also compile third party libs that the
extensions themselves are for.  image magick is a perfect example of this.

now, i'm well aware that mingw/msys is a bit of a mutt - but i personally
think that simply compiling ruby is only half the issue.  that ruby must be
able to compile and link further extensions and the libs then depend on to be
a 'real' ruby.  so, unless the ms guys are also willing to help us put
together a __free__ compiler toolchain that will work with an extconf.rb (or
simlar) method of bootstrapping extensions __and__ a means to compile the libs
they bootstrap against it seems little will be gained.

hmmm.  re-reading your post i see that you're advocating a situation in which
the compiler output itself is compatible and one might use a combination of
mingw/msys and vc++ tools.  that would indeed be a step forward - so are you
advocating producing a ruby with vc++ compilers, or are you advocating simply
having the various compilers out there produce binary abi compatible output?

in any case, thanks for thinking of this - it's definitely needed.

cheers.

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