One-Click Installer: MinGW? or VC2005?

ruby-talk
1

The One-Click Ruby Installer for Windows is at a cross-roads. The C++
compiler situation on Windows has become a complete mess because of subtle
incompatibilities and has, consequently, become a big headache for me and
extension writers.

I need to decide whether future versions of the One-Click Installer are
built with MinGW or MS VC2005 Express (both compilers are free). My bias has
been to go with VC2005 on the theory that the MS compiler will always be the
most compatible with Windows, itself.

However, Ara Howard makes a case (see below) for MinGW, so I want to have a
public discussion of the pros and cons of each path (please don't suggest
cygwin, it snot an option).

I'd like to ask that only those who have actual experience compiling
extensions for Ruby respond and that we keep the discussion to the pros and
cons of choosing MinGW or VC2005. I need to fully understand the
implications before choosing a path.

Thanks,
Curt

PS
Below, Ara argues that a VC2005 version of Ruby would be unable
to compile/use extensions built with the command sequence:

   ruby extconf.rb
   make
   make install

Isn't this incorrect? Wouldn't the sequence just become:

   ruby extconf.rb
   nmake
   nmake install

If I'm wrong here, please let me know.

···

On 7/17/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:

On Tue, 18 Jul 2006, Curt Hibbs wrote:

> No doubt, the compiler situation on Windows is a mess. There is some new

> news, Austin Zeigler has been working with the Microsoft VC++ team (who
was
> dismayed to learn the Ruby on Windows was compiled with VC++ 6) to
resolve
> the issues with Ruby and VC2005.
>
> I'll probably take over working with MS on this at some point. If we can
get
> this working, then VC2005 express would definitely be the preferred
> solution. If that fails, then it will be MinGW.

why is that though? a VC2005 will still result in a broken ruby that will
be
unable to compile things like sqlite. what i mean by that it that it will
not
allow one to

  - download sqlite
  - compile it
  - download sqlite-ruby
  - compile that

which is to say that every single ruby extension that does

  ruby extconf.rb && make && make install

will be unavialable to the windows ruby community.

if that is the case then people will immediately begin down the road
they're
on now : some will compile with mingw, some with vc++ 6, etc, etc, etc
and,
whammo, we'll be right back in the boat we're in now - binary
imcompatibility madness.

people have to realize that, if ruby is compiled with a microsoft then any
extension must also be compiled with vc++ and anything that compiles
against
as well! that's an extremely steep hill to climb - for instance totally
ansi
packages like the gsl (note i said ansi, not posix!) do not compile easily
with microsoft compilers (in fact companies charge 600$ to do it!). in
addition, 90% of the neat stuff out there like postgres, sqlite, open-ssl
-
all compile flawlessly on mingw and, therfore, allow people to compile
ruby
extensions against them. but here's the rub: microsoft doesn't provide
and
compiler __toolchain__ which plays well with 90% of the popular
open-source
projects out there. it's not the compiler that's the toughest thing -
it's
the lack of make, ld, ar, sh, etc that so many packages depend on that
makes a
microsoft based ruby so disappointing : it's a ruby that cannot be easily
extended -- one of the fundemental aspects of any modern language.

i think this is a greatly missed point. if it could be guaranteed that
__any__ ruby could compile binary extensins for itself (because it
required a
decent compiler toolchain to compile itself) then developers would be
freed to
develop binary extensions that speed ruby up and know that all ruby's
could
compile them up themselves. think about what that might to for ruby's
speed!
as it stand now making a binary installation that's portable is simply too
great a burden to expect many developers to put them selves through - we
do
this for free after all. why should tim have to figure out how to make a
cross platform image magic installation when the build process of ruby
itself
has already done so? why should the next developer have to re-invent the
wheel already again? what i'm saying is that the standards of
sh/configure/gcc, etc solve the bane of every binary ruby extension
developers
worst nightmare - portability - __already__. to not leverage this fact is
a
massive violation of dry to say the least.

in addition, having a decent environment guaranteed for every ruby opens
many,
many possibilities - imagine if this worked for any ruby

  system 'command >/dev/null 2>&1'

guess how many times that's come up on the list :wink:

in summary, a move towards any vc product will be a move not away from the
abi
incompatibilty problem - but simply towards a different one.

hopefully i will not start any flames, but that's my 2 cts.

-a

2

hi curt-

PS
Below, Ara argues that a VC2005 version of Ruby would be unable
to compile/use extensions built with the command sequence:

not unable - but with a significant amount of work.

ruby extconf.rb
make
make install

Isn't this incorrect? Wouldn't the sequence just become:

ruby extconf.rb
nmake
nmake install

If I'm wrong here, please let me know.

let's take two common examples, sqlite and gsl. in both cases you are going
to first need to compile the project itself, and then the ruby extension
written against it.

   sqlite :

     - get on google and search for how to build sqlite from source on windows.
       it doesn't come setup to do this. here are some example instructions

         http://initd.org/pub/software/pysqlite/doc/install-source-win32.html

       now, perhaps these are relevant and perhaps they're not. in particular
       note that the build is for a static library, meaning every ruby (think
       web server) process using sqlite will have the entire library in memory.
       note also that the build require gnu make (like everything else on the
       planet). most people will unlikely make it past this step.

     - get the ruby-sqlite bindings. run ruby extconf.rb. type make. oops,
       you installed ruby into a slightly different place than the person who
       build the one-click, who also used nmake. see, extconf.rb will generate
       a makefile using all the environment settings used at the time ruby was
       built, which will be one of the one-click installer maintainers'
       machines , not the end user. so, in order for extconf.rb to generate a
       workable makefile the entire environment used to build ruby __must__
       exist on the end users platform. this may or may not be a hard thing to
       get right. of course, for something simple like sqlite the end user may
       be able hack things up - then again maybe not...

     - alternatively we can require that windows users get pre-built binaries for
       sqlite and ruby-sqlite. this places the burden of maintaintance on the
       very people who are already writing the free code! in addition, it's not
       that easy to provide binaries that will be compatible for all archs and
       all versions of windows. also, we cut out tens of thousands of people who
       might contribute patches to these projects since they get nothing but a
       box of bits.

   gsl :

     - get on google and learn how to compile gsl for windows. note that the
       first four google hits have titles like 'ha ha ha' and 'nearly impossible
       to compile GSL for >> windows'. note that the fifth link is a commercial
       company selling a vc++ compiled gsl for $395.

         how to compile gsl for windows - Google Search

       dispair.

now, if one downloads mingw one gets a compile, make, and bunches of other
good stuff all at once. both sqlite and gsl can be compiled in minutes using

   ./configure --prefix=/c/usr/local && make && make install

same goes for ruby - compiles without a hitch. next we can download the
sqlite and gsl bindings and simply do

   ruby extconf.rb && make && make install

done.

the crux of the issue isn't that vc++ is a bad compiler - it's obviously not -
it's that many, many good ruby extensions are actually just hooks into 3rd
parth software which, itself, requires a 'minimal system' to compile: sh, ld,
ar, gcc, etc. and that it's precisely this 'minimal system', not only the
compiler, which is 'remembered' by ruby during compile time and used to create
rbconfig.rb, which is the foundation of mkmf.rb and extconf.rb. it's
interesting to run this command on a machine where ruby is installed:

   ruby -r yaml -r rbconfig -e' y Config::CONFIG '

do so and you'll see all sorts of stuff ruby considers important for building
   and installing things like

   ...
   MAKEDIRS: mkdir -p
   ...
   AR: ar
   ...
   LN_S: ln -s
   ...
   RANLIB: ranlib
   ...
   LDSHARED: gcc -shared
   ...
   YACC: bison -y
   ...
   STRIP: strip -S -x
   ...
   NROFF: /usr/bin/nroff
   ...
   INSTALL_PROGRAM: /usr/bin/install -c
   ...

and this is only the tip of the iceberg - none of which include the compiler
itself. ruby considers these programs essential for building itself and it's
totally legit for any extension to make use of these values during
configure/build time and, in fact, many do. these programs may or may not
have to exist on end users machines in the same location (or at least in PATH)
and the one-click builder's machine for them to be used. so, this is an
example 'minimal system' ruby might use and, by coincidence, is very similar
the the environment provided by mingw.

now, that's the for. here's the against: i can't swear that mingw is as
'compatible' with microsoft as a microsoft produced compiler - common sense
says it will not be. on the other hand, microsoft seems to have compatibilty
issues even between it's own compilers so maybe this gut feeling is wrong. in
any case i'm not expert here and would defer to illumination from one.

one last thing - thanks so much for doing this work curt, community is far
better for it.

cheers.

-a

···

On Wed, 19 Jul 2006, Curt Hibbs wrote:
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama

3

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.

What does that mean for non-Ruby packages like sqllite and openssl? It may
mean that we need to provide custom distros of these libraries wrapped into
Ruby-gems that know how to interact with how we sense what's in the
environment when we install. If this sounds like a total pain in the tail:
it is, but my point is that we're not doing our users any favors by shifting
the pain onto them. My personal point of view (which many of you may
reasonably disagree with) is that Ruby applications should gain the
reputation of being braindead-easy to install on nearly any machine. For
better or worse, that means a lot more attention paid by developers (that's
us) to these issues.

···

On 7/18/06, Curt Hibbs <ml.chibbs@gmail.com> wrote:

The One-Click Ruby Installer for Windows is at a cross-roads. The C++
compiler situation on Windows has become a complete mess because of subtle
incompatibilities and has, consequently, become a big headache for me and
extension writers.

4

Below, Ara argues that a VC2005 version of Ruby would be unable
to compile/use extensions built with the command sequence:

  ruby extconf.rb
  make
  make install

Isn't this incorrect? Wouldn't the sequence just become:

  ruby extconf.rb
  nmake
  nmake install

If I'm wrong here, please let me know.

Ara has already covered this in detail, but to clarify:

  ruby extconf.rb
  nmake
  nmake install

can indeed work on Windows, for simple extensions.

It's not uncommon, at a minimum, to have to tweak the
extconf.rb, though. Often an extconf.rb specifies
gcc-specific compiler flags, or looks for the presence
of libraries that are named differently, etc.

Sometimes it's a simple fix, such as modifying the
extconf.rb to eliminate lines like:

  CFLAGS << " -Wall -Wno-comment"
  CFLAGS << " -Wno-unused"

...on the Windows build.

But for more complex extensions, building on windows
(with nmake and cl.exe) can be far less trivial.

I recently compiled the RMagick extension on Windows,
and it was a complete hack job to get it to compile
with microsoft's tools.

First of all, RMagick uses ./configure to actually
build the extconf.rb from extconf.rb.in.
So there's no extconf.rb to even work with initially.

It also uses ./configure to build a lengthy header
file, rmagick_config.h.

Ultimately, I ended up building RMagick on linux,
and bringing extconf.rb and rmagick_config.h back
to Windows, and tweaking them enough to compile with
nmake + cl.exe.

Here's an example of the tweaks to extconf.rb:

Replace:

  $CFLAGS = "-Wall -g "
  $CPPFLAGS = "-DRUBY_VERSION=#{VERSION_NUMBER} -I/opt/include/ImageMagick-6.2.8"

with:

  $CFLAGS = "-DWIN32 -DRUBY_VERSION=#{VERSION_NUMBER} -I../../../ImageMagick-6.2.8"
  $LIBPATH << "../../../ImageMagick-6.2.8/VisualMagick/lib"

etc.

And I was lucky ImageMagick itself came with the
ability to build with Visual Studio. There are other
projects, such as the ones Ara mentioned, and puredata,
and (I think) ruby-gnome2 and ruby-gstreamer that don't
build under visual studio at all.

So, yeah... If we could build ruby extensions AND the
libraries they rely on with ./configure && make, on
Windows... That sounds far nicer than the current hassles
I've had trying to build complex extensions and their
associated libraries with microsoft's tools.

That said, I must admit... I tried to get mingw/msys to
work for me, and I had weird problems with it. I asked
for help in #mingw on irc.freenode.net on a couple occasions, but never got a response. But clearly, Ara
has gotten it to work, so there's hope. <grin>

Regards,

Bill

···

From: "Curt Hibbs" <ml.chibbs@gmail.com>

5

Given that the current situation can be to a large extent attributed to the
perverted mind of somebody at Microsoft who has consistently decided to break
binary compatibility in (nearly all?) new releases of their compilers, doesn't
the burden of proof fall on VC2005? It seems to me that very heavy evidence
would be needed to justify that choice, since it appears very likely to lead to
problems like those we're experiencing now, if any conclusion is to be drawn
from recent history.

So far, we've seen the following arguments for MS VC2005 and MinGW,
respectively:
(1) VC 2005 should be more compatible with Windows
(2) MinGW (plus MSYS) provides an adequate environment to compile the
    third-party libraries against which you want to link your Ruby extension.

While (1) is likely, we can't know the extent of any future incompatibilities,
and it is indeed possible that the people behind MinGW keep them under
control. To my eyes, (1) is easily counter-balanced by the almost certain
incompatibilities "with themselves" MS' compilers seem bound to suffer from,
given their track record. How long will VC 2005 live before it's removed from
MS' sites?

However, the argument deserves careful consideration, so I'd ask for reports
of _current_ problems caused by MinGW. In other words, I'd like to see actual
reasons why MinGW would *not* be a good choice right now: specific problems
that can only be solved by switching to MS' compiler of the day.

Here are a few other minor arguments for MinGW:
* availability: MinGW will not disappear the way VC6 did
* redistribution: is it allowed to redistribute VC 2005 at all? And to bundle
  it with other software? A "Ruby devel. kit" (in a similar spirit as Instant
  Rails) including MSYS+MinGW is at least conceivable -- would it be legally
  possible with VC?
* cross-compilation: one thing I like about MinGW is that it can be used to
  cross-compile extensions under non-win32 platforms. It allows me to provide
  win32 binaries for my extensions without having to use win32 myself. A few
  other people might also appreciate that. It could also simplify the creation
  of a build farm as proposed by Francis Cianfrocca.

There's another probably more important reason to go MinGW: it offers an
easier migration path, as existing extensions compiled with VC6/MinGW (which
might well be the majority, since recent OCI distros used the mswin32 build,
and the installer was built with VC6 historically, IIRC) would probably still
work. However, I must admit I'm speculating since some people have claimed
that MinGW-compiled extensions were not always compatible with VC6 Ruby
builds, although the reports were often vague. And I certainly don't remember
nobu saying that MinGW is incompatible, but rather the opposite.
Now, I don't know if that "99% compatibility" is commutative or not, either,
but I'd like to believe it is.

Again, I feel we'd have to be shown specific cases where MinGW was not good
enough -- there's already ample evidence showing that it does, more often than
not, work just fine. And at any rate, it's still most probably better, as far
as backwards compatibility goes, than VC 2005, which uses a different runtime.

···

On Wed, Jul 19, 2006 at 12:22:16AM +0900, Curt Hibbs wrote:

The One-Click Ruby Installer for Windows is at a cross-roads. The C++
compiler situation on Windows has become a complete mess because of subtle
incompatibilities and has, consequently, become a big headache for me and
extension writers.

I need to decide whether future versions of the One-Click Installer are
built with MinGW or MS VC2005 Express (both compilers are free). My bias has
been to go with VC2005 on the theory that the MS compiler will always be the
most compatible with Windows, itself.

--
Mauricio Fernandez - http://eigenclass.org - singular Ruby

6

Having used MS C since before it became Visual I can certainly attest
to it being a strong compiler. However, over the past few years it
seems as if MS has gone out of its way to alienate long term users of
their programming products. And it's not just the incompatibilities
introduced in VS.NET - look at what's happened to VB, OLE and MFC.

People spent 10 years becoming expert in these technologies just to
see them thrown away.

My experience is that you cannot write code using an MS platform and
expect it to be even compilable 5 years later. This is one of the main
reasons why I have switched to Open Source wherever possible - I have
code I wrote 20 years ago written in K&R C that still compiles and
works but anything I wrote in the 90s is a complete write-off.

As for the toolchain - while it may seem alien to people who have only
ever programmed with MS products, it really isn't that hard to get
your head around. More and more people are developing in a mixed
environment - e.g. coding on Windows workstations and deploying on
Linux servers. To have one set of tools and commands to remember makes
a lot of sense.

As for MS products being more compatible with Windows - if you've ever
come across the problem of trying to compile across different versions
of MSCVRT*.DLL you'll find that hard to swallow.

Personally I'm not interested in the slightest in making Ruby more
friendly to Windows but I am interested in making Windows more
friendly to Ruby.

Nearly all the good stuff we enjoy in Ruby on Windows comes from its
*nix background - using MinGW makes it a heck of a lot easier to
compile all those libs.

I say go for MinGW - it will still be here in 5 years time and it
narrows the gap between the Windows and *nix development environments.

My 2p

Regards,
Sean

···

On 7/18/06, Curt Hibbs <ml.chibbs@gmail.com> wrote:

The One-Click Ruby Installer for Windows is at a cross-roads. The C++
compiler situation on Windows has become a complete mess because of subtle
incompatibilities and has, consequently, become a big headache for me and
extension writers.

I need to decide whether future versions of the One-Click Installer are
built with MinGW or MS VC2005 Express (both compilers are free). My bias has
been to go with VC2005 on the theory that the MS compiler will always be the
most compatible with Windows, itself.

7

Curt Hibbs wrote:

The One-Click Ruby Installer for Windows is at a cross-roads. The C++
compiler situation on Windows has become a complete mess because of subtle
incompatibilities and has, consequently, become a big headache for me and
extension writers.

I need to decide whether future versions of the One-Click Installer are
built with MinGW or MS VC2005 Express (both compilers are free). My bias has
been to go with VC2005 on the theory that the MS compiler will always be the
most compatible with Windows, itself.

However, Ara Howard makes a case (see below) for MinGW, so I want to have a
public discussion of the pros and cons of each path (please don't suggest
cygwin, it snot an option).

I'd like to ask that only those who have actual experience compiling
extensions for Ruby respond and that we keep the discussion to the pros and
cons of choosing MinGW or VC2005. I need to fully understand the
implications before choosing a path.

Is cross-compiling/linking with GCC on a GNU platform a viable third option? MinGW tends to lag "real" GCC. Given that you plan a Linux release of the One-Click Ruby Installer, could you save yourself some hassles with a cross-builder?

8

Curt Hibbs wrote:

This is the whole point of this thread. It appears that the only safe
thing
is that the Ruby runtime and all extensions that its uses (both those
included with the one-click installer and those provided by third
parties)
need to be using the same compiler and that compiler needs to be freely
available.

I have two choices VS2005 Express and MinGW. What I really want to know
(as
succinctly as possible) is what the pros and cons are for each path.

Curt

What we're really talking about is building all kinds of unix-derived
tools on Windows. Ruby, OpenSSL, IConv, ZLib - all the common things on
a POSIX-based system. If Ruby and all third-party extensions need to be
build using the same compiler, then we're talking about industry
standardization for porting to Windows. That in itself in a large
barrier. So, any unix-derived tool running on Windows may need to be
recompiled to work smoothly with any other.

So my question is which represents the lowest barrier to entry for
extension developers? If MinGW install & usage can be made simple for
the mouse-addicted Windows user, then MinGW it is (see Charlie's post
about getting MinGW to actually work). Until then, I suspect there will
be a lot of justification for VC.

I vote for MinGW for the following reasons.

* It's more compatible with the standard unix build tools and processes.
* Making a working MinGW system is something a handful of folks could
put together and pass along to everyone interested in making Ruby
extensions. This is much less work than each extension developer
figuring out how to recompile the third-party libs (i.e. MySQL).
* It seems to run faster, which helps when demoing to
Pointy-Haired-Bosses in Microsoft-centric shops.

I surprised myself, beause I have VC and have no clue how to use MinGW
(I'll have to google for it just to find the web page!).

···

--
Posted via http://www.ruby-forum.com/\.

9

Thanks for taking the time to post such a detailed account. Now that you
mention it, I have encountered the very same problem myself with OpenSSL. I
actually gave up trying to solve the compile problem when I found a
pre-built binary for OpenSSL.

Curt

···

On 7/18/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:

On Wed, 19 Jul 2006, Curt Hibbs wrote:

hi curt-

> PS
> Below, Ara argues that a VC2005 version of Ruby would be unable
> to compile/use extensions built with the command sequence:

not unable - but with a significant amount of work.

>
> ruby extconf.rb
> make
> make install
>
> Isn't this incorrect? Wouldn't the sequence just become:
>
> ruby extconf.rb
> nmake
> nmake install
>
> If I'm wrong here, please let me know.

let's take two common examples, sqlite and gsl. in both cases you are
going
to first need to compile the project itself, and then the ruby extension
written against it.

  sqlite :

    - get on google and search for how to build sqlite from source on
windows.
      it doesn't come setup to do this. here are some example
instructions

http://initd.org/pub/software/pysqlite/doc/install-source-win32.html

      now, perhaps these are relevant and perhaps they're not. in
particular
      note that the build is for a static library, meaning every ruby
(think
      web server) process using sqlite will have the entire library in
memory.
      note also that the build require gnu make (like everything else on
the
      planet). most people will unlikely make it past this step.

    - get the ruby-sqlite bindings. run ruby extconf.rb. type
make. oops,
      you installed ruby into a slightly different place than the person
who
      build the one-click, who also used nmake. see, extconf.rb will
generate
      a makefile using all the environment settings used at the time ruby
was
      built, which will be one of the one-click installer maintainers'
      machines , not the end user. so, in order for extconf.rb to
generate a
      workable makefile the entire environment used to build ruby __must__
      exist on the end users platform. this may or may not be a hard
thing to
      get right. of course, for something simple like sqlite the end user
may
      be able hack things up - then again maybe not...

    - alternatively we can require that windows users get pre-built
binaries for
      sqlite and ruby-sqlite. this places the burden of maintaintance on
the
      very people who are already writing the free code! in addition,
it's not
      that easy to provide binaries that will be compatible for all archs
and
      all versions of windows. also, we cut out tens of thousands of
people who
      might contribute patches to these projects since they get nothing
but a
      box of bits.

  gsl :

    - get on google and learn how to compile gsl for windows. note that
the
      first four google hits have titles like 'ha ha ha' and 'nearly
impossible
      to compile GSL for >> windows'. note that the fifth link is a
commercial
      company selling a vc++ compiled gsl for $395.

how to compile gsl for windows - Google Search

      dispair.

now, if one downloads mingw one gets a compile, make, and bunches of other
good stuff all at once. both sqlite and gsl can be compiled in minutes
using

  ./configure --prefix=/c/usr/local && make && make install

same goes for ruby - compiles without a hitch. next we can download the
sqlite and gsl bindings and simply do

  ruby extconf.rb && make && make install

done.

the crux of the issue isn't that vc++ is a bad compiler - it's obviously
not -
it's that many, many good ruby extensions are actually just hooks into 3rd
parth software which, itself, requires a 'minimal system' to compile: sh,
ld,
ar, gcc, etc. and that it's precisely this 'minimal system', not only the
compiler, which is 'remembered' by ruby during compile time and used to
create
rbconfig.rb, which is the foundation of mkmf.rb and extconf.rb. it's
interesting to run this command on a machine where ruby is installed:

  ruby -r yaml -r rbconfig -e' y Config::CONFIG '

do so and you'll see all sorts of stuff ruby considers important for
building
  and installing things like

  ...
  MAKEDIRS: mkdir -p
  ...
  AR: ar
  ...
  LN_S: ln -s
  ...
  RANLIB: ranlib
  ...
  LDSHARED: gcc -shared
  ...
  YACC: bison -y
  ...
  STRIP: strip -S -x
  ...
  NROFF: /usr/bin/nroff
  ...
  INSTALL_PROGRAM: /usr/bin/install -c
  ...

and this is only the tip of the iceberg - none of which include the
compiler
itself. ruby considers these programs essential for building itself and
it's
totally legit for any extension to make use of these values during
configure/build time and, in fact, many do. these programs may or may not
have to exist on end users machines in the same location (or at least in
PATH)
and the one-click builder's machine for them to be used. so, this is an
example 'minimal system' ruby might use and, by coincidence, is very
similar
the the environment provided by mingw.

now, that's the for. here's the against: i can't swear that mingw is as
'compatible' with microsoft as a microsoft produced compiler - common
sense
says it will not be. on the other hand, microsoft seems to have
compatibilty
issues even between it's own compilers so maybe this gut feeling is
wrong. in
any case i'm not expert here and would defer to illumination from one.

one last thing - thanks so much for doing this work curt, community is far
better for it.

cheers.

10

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

···

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.

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

11

Bill Kelly wrote:

I recently compiled the RMagick extension on Windows,
and it was a complete hack job to get it to compile
with microsoft's tools.

I'm sure Kaspar feels your pain :slight_smile:

12

M. Edward (Ed) Borasky wrote:

Is cross-compiling/linking with GCC on a GNU platform a viable third option? MinGW tends to lag "real" GCC. Given that you plan a Linux release of the One-Click Ruby Installer, could you save yourself some hassles with a cross-builder?

By the way, the people who build R for Windows have a very extensive tool set. The build process, however, is complex, quite brittle and changes often. I went through it once (on a laptop dual-booted with Linux :slight_smile: ) and I must say if you're good at following directions exactly to the letter, you've got at least a 50% chance of a successful build. Surely Microsoft makes something a little better than that. :slight_smile:

13

Sean O'halpin wrote:

The One-Click Ruby Installer for Windows is at a cross-roads. The C++
compiler situation on Windows has become a complete mess because of subtle
incompatibilities and has, consequently, become a big headache for me and
extension writers.

I need to decide whether future versions of the One-Click Installer are
built with MinGW or MS VC2005 Express (both compilers are free). My bias has
been to go with VC2005 on the theory that the MS compiler will always be the
most compatible with Windows, itself.

Having used MS C since before it became Visual I can certainly attest
to it being a strong compiler. However, over the past few years it
seems as if MS has gone out of its way to alienate long term users of
their programming products. And it's not just the incompatibilities
introduced in VS.NET - look at what's happened to VB, OLE and MFC.

MS needs to evolve also, do you expect MS to continue to enhance MS-DOS.
It can't sit still while the competition passes it by and the fanatics
complain about security.

You can't bitch about MS and then bitch because they try to make it
better.

People spent 10 years becoming expert in these technologies just to
see them thrown away.

My experience is that you cannot write code using an MS platform and
expect it to be even compilable 5 years later. This is one of the main
reasons why I have switched to Open Source wherever possible - I have
code I wrote 20 years ago written in K&R C that still compiles and
works but anything I wrote in the 90s is a complete write-off.

You aren't making any sense. MS is a very ANSI standard compiler, so if
you "truly" wrote it to be K&R it should work.

As for the toolchain - while it may seem alien to people who have only
ever programmed with MS products, it really isn't that hard to get
your head around. More and more people are developing in a mixed
environment - e.g. coding on Windows workstations and deploying on
Linux servers. To have one set of tools and commands to remember makes
a lot of sense.

It make a lot of sense to those who have used it before.
It you are new to Ruby and need to compile it for the first and then
have to go thru the problem of setting up a toolchain, MinGW, etc...this
becomes a huge turnoff for using Ruby.

Windows products should use Windows compiler...VC++.

As for MS products being more compatible with Windows - if you've ever
come across the problem of trying to compile across different versions
of MSCVRT*.DLL you'll find that hard to swallow.

I haven't experienced, but I have heard of others who have.

Personally I'm not interested in the slightest in making Ruby more
friendly to Windows but I am interested in making Windows more
friendly to Ruby.

They you should leave this thread...we are trying to find a way to make
both sides happy and bring more users and developers to the Ruby
corner...Linux and Windows.

Nearly all the good stuff we enjoy in Ruby on Windows comes from its
*nix background - using MinGW makes it a heck of a lot easier to
compile all those libs.

This has NOTHING to do with which compiler to use for Windows.
Windows is Windows, not *nix!
You are just a Windows hater and your comments don't hold any weight
here.

I say go for MinGW - it will still be here in 5 years time and it
narrows the gap between the Windows and *nix development environments.

But it widens the gap on Windows and the evolution of Windows.

···

On 7/18/06, Curt Hibbs <ml.chibbs@gmail.com> wrote:

--
Posted via http://www.ruby-forum.com/\.

14

Sean O'Halpin wrote:

People spent 10 years becoming expert in these technologies just to
see them thrown away.

in some cases, its called progress.

Nearly all the good stuff we enjoy in Ruby on Windows comes from its
*nix background - using MinGW makes it a heck of a lot easier to
compile all those libs.

it just proves ruby is full of unixism and is unixcentric as opposed to
being
windows centric. Thats its heratige, it was written on unix and uses
what it knows.

Now me, I feel left out in the cold since I use OpenWatcom...

the problem I think, ruby assumes too much about your system.

what needs to be done with the one click installer is not have it
assume its
on the system that built it. it would be nice, if there was a generic
config
that could be changed so MAKE=nmake.exe and CC=cl.exe that overrides
whatever ruby is assuming...

There is no real easy way out and I tink that mingw will/should get
ratified
as 'TheOne(tm)'. As long as people understand that MinGW is minimal and
some full blown './configure && make' its not designed to be cygwin,
that Min is for Minimal.

In the ruby extension case, 'minimal' should be enough to build any
required extensions.
Now packaging it with the one click installer would be nice, we could
assume then (ooh assumptions!) that a specific version of ruby on
windows will have a specific version of mingw + supporting cast
members....

-stu

15

Wikipedia has a good description:

  MinGW - Wikipedia

Curt

···

On 7/19/06, Kevin Williams <kevwil@gmail.com> wrote:

Curt Hibbs wrote:
> This is the whole point of this thread. It appears that the only safe
> thing
> is that the Ruby runtime and all extensions that its uses (both those
> included with the one-click installer and those provided by third
> parties)
> need to be using the same compiler and that compiler needs to be freely
> available.
>
> I have two choices VS2005 Express and MinGW. What I really want to know
> (as
> succinctly as possible) is what the pros and cons are for each path.
>
> Curt

What we're really talking about is building all kinds of unix-derived
tools on Windows. Ruby, OpenSSL, IConv, ZLib - all the common things on
a POSIX-based system. If Ruby and all third-party extensions need to be
build using the same compiler, then we're talking about industry
standardization for porting to Windows. That in itself in a large
barrier. So, any unix-derived tool running on Windows may need to be
recompiled to work smoothly with any other.

So my question is which represents the lowest barrier to entry for
extension developers? If MinGW install & usage can be made simple for
the mouse-addicted Windows user, then MinGW it is (see Charlie's post
about getting MinGW to actually work). Until then, I suspect there will
be a lot of justification for VC.

I vote for MinGW for the following reasons.

* It's more compatible with the standard unix build tools and processes.
* Making a working MinGW system is something a handful of folks could
put together and pass along to everyone interested in making Ruby
extensions. This is much less work than each extension developer
figuring out how to recompile the third-party libs (i.e. MySQL).
* It seems to run faster, which helps when demoing to
Pointy-Haired-Bosses in Microsoft-centric shops.

I surprised myself, beause I have VC and have no clue how to use MinGW
(I'll have to google for it just to find the web page!).

16

Mauricio Fernandez wrote:

Here are a few other minor arguments for MinGW:
* availability: MinGW will not disappear the way VC6 did
* redistribution: is it allowed to redistribute VC 2005 at all? And to bundle
  it with other software? A "Ruby devel. kit" (in a similar spirit as Instant
  Rails) including MSYS+MinGW is at least conceivable -- would it be legally
  possible with VC?

A small addition to Mauricio's point: if a compiler is distributed with ruby, then that will benefit not just developers but users of software that depends on C code generators such as RubyInline.

(Personally, my interest is in Cgenerator and the RedShift simulation framework. There's no way to distribute a binary extension because the extension needs to be generated at run time according to the flow equations, guards, transitions, and other specifications provided in the user's ruby code.)

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

17

+1 for this idea - a one-click binary installer and a one-click
build-from-source-kit installer would be great.

Regards,
Sean

···

On 7/18/06, Mauricio Fernandez <mfp@acm.org> wrote:

A "Ruby devel. kit" (in a similar spirit as Instant
Rails) including MSYS+MinGW is at least conceivable

18

It's not uncommon, at a minimum, to have to tweak the
extconf.rb, though. Often an extconf.rb specifies
gcc-specific compiler flags, or looks for the presence
of libraries that are named differently, etc.

Then this is a bug with that extension. Anyone who assumes GCC only on
their extensions is being a platform chauvinist and possibly making
unreasonable assumptions for you. File a bug.

I recently compiled the RMagick extension on Windows,
and it was a complete hack job to get it to compile
with microsoft's tools.

First of all, RMagick uses ./configure to actually
build the extconf.rb from extconf.rb.in.
So there's no extconf.rb to even work with initially.

IMO, RMagick should not be using a sh-based configure script. We
should be using a Ruby-based configure script. Perl has done this; so
should we.

So, yeah... If we could build ruby extensions AND the
libraries they rely on with ./configure && make, on
Windows... That sounds far nicer than the current hassles
I've had trying to build complex extensions and their
associated libraries with microsoft's tools.

I understand that this would make your life easier, but it's not the
right answer. There *are* better answers than this, and we should take
advantage of them. The "parent" libraries may be more difficult, but
we should bitch to the upstream authors, too.

MinGW is ... not the best choice. It's not as nearly as bad a choice
as cygwin, but it is definitely an inferior choice to VC2005. Here's a
question: what if we tried to convince Microsoft to build a
gcc-wrapper? That is, something for VC2005 that can convert gcc
command-lines to VC2005 command-lines automatically? IIRC, the Mars
compiler had something similar (cl-to-mars converter).

-austin

···

On 7/18/06, Bill Kelly <billk@cts.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

19

No. I would stop using the One-Click Ruby Installer if that were the
direction chosen and start offering my own based on something more
useful. Cross-compiling should be used only if that's the *only* way
to get a good build for a platform (e.g., PalmOS).

-austin

···

On 7/18/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

Is cross-compiling/linking with GCC on a GNU platform a viable third
option? MinGW tends to lag "real" GCC. Given that you plan a Linux
release of the One-Click Ruby Installer, could you save yourself some
hassles with a cross-builder?

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

20

right. the question is whether it's reasonable and/or healthly for the ruby
community to require pre-built binaries for every peice of third party
software or not? my personal feeling is that be making that requirement, no
matter which compiler you choose, you'll see abi incompats because who knows
what, for example, the openssl guy used. it just seems like the only way out
is to at least provide an easy path for people who want to build stuff because
otherwise it's like you have to get everyone, including 3rd party people and
extension writers, to agree on one compiler and that seems, frankly,
impossible.

the caveat, however, is whether mingw can cut the mustard. i've not heard any
reason why it couldn't - but i am simply not experience enough on windoze to
know for sure.

kind regards.

-a

···

On Wed, 19 Jul 2006, Curt Hibbs wrote:

Thanks for taking the time to post such a detailed account. Now that you
mention it, I have encountered the very same problem myself with OpenSSL. I
actually gave up trying to solve the compile problem when I found a
pre-built binary for OpenSSL.

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