One-Click Installer: MinGW? or VC2005?

Ruby
101

On Sat, 22 Jul 2006, Austin Z. wrote:

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.

why is that? gcc is, far and above, the most platform indepedant
compiler in
the world? and it’s free! how does that make one a chauvinist?

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.

by using sh configure scripts one can often leverage the significant
amount of
configureation work a third party lib has already written such as all
that the
gsl uses to optimize floating point maths for a particular platform -
it’s
totally unresonable to expect someone to re-write all that.
./configure.sh is
easily one of the most complex open source software packages out there -
i
pitty the person whose task it is to reproduce it! :wink:

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.

i think my point, as an extension writer, is that i do this for free,
have a
wife, kids, 50hr/wk job, 3 dogs, etc. i do not want people bitching to
me.
if i’ve written something that works using the most platform independant
tools
out there i’d like downstream people to contribute to making my software
work

  • not the otherway around! in particular when those downstream people
    are on
    a platform whose funding contributes to undermining the toolset i’m
    using to
    provide them free software! seriously austin, we agree on many things,
    but do
    you really think all the people there contributing code should be
    required to
    do more?

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).

not a bad idea. however, we still need bison, ar, ld, yacc, make, sh
and
friends to truely have a compatible build environment, which is what
this
thread is really about. btw. i’m not saying the msys approach to
shoehorning
windows into being a compatible environment is the best one, but,
afaik,
it’s by far the only one that has potential to marry mac, *nix, and
windoze while making extensions that require 3rd party software (the
majority)
available to the biggest number of users.

kind regards.

-a

102

Hello,

In message “Re: One-Click Installer: MinGW? or VC2005?”
on Jul.22,2006 00:13:40, [email protected] wrote:
| Mmm. This may or may not be the case. This is why I have been trying
| to collect information for an ongoing conversation with Microsoft.
| They are … concerned that we are still using VC6 as our compiler and
| want to see what can be helped to provide better support for moving
| Ruby to VC8.

We (maybe) already finished to be able to compile ruby with VC8.
About me, to compile all libraries with VC8 is very troublesome.
And to distribute VC8 binary, I must think how users get runtime
which matches with the manifest of my distribution (Yah, say good
bye to DLL hell, and say hello to manifest hell!)
It’s the reason why I’m using VC6.

So… Microsoft should support not only us but also all authors
who write libraries.
If they maintain the binary compatibility, they might not have
had to use extra effort :slight_smile:

Regards,

103

On 7/21/06, Patrick H. [email protected] wrote:

On 7/21/06, stu [email protected] wrote:

Doesnt microsofts license forbid redistribution of VC Express anyway?

On the issue of licensing, can we distribute MSCVRT with an
application that was not built with VC? I seem to remember this being
something of an issue.

IIRC, no. However, Microsoft’s licence does allow the distribution of
the runtime with VC+±built tools.

-austin

104

On 7/21/06, stu [email protected] wrote:

And finally, it is always a good decision to use the compiler from the
system vendor. Unix guys should remember this. Even if it is a totally
strange HP PA-RISC compiler. This simply gives the best compatibility.

This is true. Suns compiler was always better than gcc and same to for
ibms power compiler vs gcc…

I’d rate gcc over msvc but under the Intel C compiler.

Your rate would be wrong, demonstrably. MSVC is not only the more
performant compiler on Windows, it is the more compliant compiler at
this point.

I smell a rat. Most of your complaints are bogus.

Doesnt microsofts license forbid redistribution of VC Express anyway?

This is a non-issue. The people who want a Ruby+compiler combination
are wanting something unreasonable. Ruby should not come with a C/C++
compiler under any circumstance.

-austin

105

On 7/21/06, [email protected] [email protected] wrote:

And finally, it is always a good decision to use the compiler from the
system vendor. Unix guys should remember this. Even if it is a totally
strange HP PA-RISC compiler. This simply gives the best compatibility.

wow. that’s strange - i’ve worked on hp-ux, vax, solaris, sunos, and linux
over the last 8 years and have found, without exception, that gcc produces the
fastest code. additionally, the compiler is much (read that MUCH) more
standards compiant. just getting variardic c functions working across those
platforms was a chore - unless one uses gcc/glib…

I won’t use gcc on any platform where it isn’t the native compiler.
Period. GCC binaries are horridly slow and unstable on HP-UX, despite
the disaster that is aCC. GCC binaries are unusable on AIX, despite
the mess called xlC. GCC binaries are painfully slow compared to Sun
Studio built binaries.

-austin

106

On Sat, 22 Jul 2006, Austin Z. wrote:

This is a non-issue. The people who want a Ruby+compiler combination
are wanting something unreasonable. Ruby should not come with a C/C++
compiler under any circumstance.

but building extension is a language feature - if what you say is true
then
ruby should not ship with mkmf.rb.

-a

107

On 7/21/06, [email protected] [email protected] wrote:

On Sat, 22 Jul 2006, Austin Z. wrote:

This is a non-issue. The people who want a Ruby+compiler combination
are wanting something unreasonable. Ruby should not come with a C/C++
compiler under any circumstance.
but building extension is a language feature - if what you say is true then
ruby should not ship with mkmf.rb.

No, Ara, it’s not a language feature. It’s something that can be
done, but you’ll note that Ruby doesn’t ship with a compiler on any
other platform. And don’t tell me that that’s because those other
platforms include compilers – you don’t put a compiler on a real
production machine.

A C/C++ compiler is wholly separate from Ruby and must be treated as
such.

-austin

108

On Sat, 22 Jul 2006, Austin Z. wrote:

those
platforms was a chore - unless one uses gcc/glib…

I won’t use gcc on any platform where it isn’t the native compiler.
Period. GCC binaries are horridly slow and unstable on HP-UX, despite
the disaster that is aCC. GCC binaries are unusable on AIX, despite
the mess called xlC. GCC binaries are painfully slow compared to Sun
Studio built binaries.

ok austin, i believe your experience. however you, of all people,
should be
able to show us numbers with ruby extensions and/or ruby itself. the
only
numbers posted thus far show the opposite.

my experience, porting a 90,000 line c project to linux/nix/vax was that
the
only possible way to do so, in this specific case, was to to use gcc.
code
that crashes quickly being of very little use to us. mind you, it was
crappy
code, but we’re talking about opening up ruby to third party libs where,
for
better or worse, these is indeed reams of crappy c code. this is a real
issue.

-a

109

On 7/21/06, [email protected] [email protected] wrote:

here’s a challenge:

I won’t take your challenge for several reasons. I will forward it on
to the VS team when I’m back from vacation.

My reasons:

  1. I’m currently on vacation.
  2. When I’m back from vacation, I have a full work schedule.
  3. I need to continue work on things that matter to me, which include
    PDF::Writer and my impending wedding.
  4. I am handing the communication with the VS team over to Curt as
    soon as I have a chance to pull everything together.
  5. I don’t need gsl.

I oppose the use of MinGW for the Ruby installer. Vehemently. It’s
not the right way, and will only complicate things for 64-bit
Windows support (which Vista will have right out of the box). The API
support for MinGW is behind and it doesn’t interface well with the
newer parts of Windows because it’s built on an outdated runtime that
still has security issues.

The problem isn’t the toolchain provided by the compiler at this
point; it is that Ruby’s toolchain isn’t sufficiently cross-platform
(a la Perl’s “perl Makefile.PL” or Python’s distutils) and needs to
grow up so that you don’t even have to think about this.

I am also not convinced that everything needs to be compiled with
VS2005 to make it work; only extensions and those libraries which do
not provide an alternative to the use of “errno” directly (they should
be across API calls).

-austin

110

On 7/21/06, Austin Z. [email protected] wrote:

should we.
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).

What happens when VC2k5 goes the way of VC6? What happens when we can
no
longer acquire VC2k5 and Microsoft has moved on to their new VC2k7fx3
product, with new features, new tool chain, and different compatibility
problems? How long until MS changes the licensing, or distribution of
their
toolchain in such a way that we have to move to either an open source
option, or to the newest MS provided solution? 6 months? A year? 3
years?
We don’t know, and we can’t do anything to stop them.

The current MSYS+MinGW can’t be pulled out from underneath us, ever. I
greatly dislike the idea of relying on ANY non-open product to provide
the
prodominent Windows distribution of Ruby. You obviously disagree, and
that’s completely within your right to do. I also know you’ve put in a
lot
of work to try to get VC2k5 to compile Ruby and its dependencies, which
is a
great thing, and many of us appreciate the choice that that work can
bring.
But I also know that today, in under 10 minutes I download MSYS+MinGW +
Ruby
Source, and had it compiled and running test scripts.

-austin

111

On Sat, 22 Jul 2006, Austin Z. wrote:

The better question is not “easier”; the better question is “which
will give me better” binary results? The answer to that nearly every
time will be the Microsoft toolchain.

here’s a challenge:

setup a binary gsl build we can download and test using ms toolchain
only - no
msys or cygwin allowed. i maintain you, or the ms developers, will not
be
able to provide any binary results let alone better ones. keep
in
mind that the gsl is nothing but pure ansi c code - it should be a
trivial
task to get it working under windows. i think this would be a great
litmus
test since gsl is a top download on rubyforge, a significant peice of
ansi
compliant c code with no platform depedancies, and extremely useful to
the
ruby community. which begs the question: why do people charge 400$ to
compile
using ms toolchain? why did i get paid to compile for windows using
msys
toolchain? why did it take me about 10 minutes to do so?

i’ll be happy to have it shown that i’m an idiot (not the first time)
and that
it’s trivial to get the gsl running using the one-click and ms toolchain
but
until then i’ll maintain that an ms based ruby is broken and continute
to do
so until people show some actual code being compiled, run, and profiled
vs all
the talk.

gauntlet thrown!

kind regards.

btw. my msys derived version is here

http://codeforpeople.com/lib/ruby/rb-gsl-win/

-a

112

On 7/21/06, Austin Z. [email protected] wrote:

Not quite. MinGW won’t give you 64-bit Windows support.

Nor will Visual C++ 2005 Express Edition - it’s 32-bit only.

The better question is not “easier”; the better question is “which
will give me better” binary results? The answer to that nearly every
time will be the Microsoft toolchain.

Apparently the Intel C/C++ compiler wins on this score (haven’t used it
myself,
so I am not speaking from experience, just from what I’ve read on the
net).

Personally, I don’t think there is a no-brainer answer to this
question - any decision will
surely be a compromise between competing forces. The question we Win32
users of Ruby
need to address is what matters most. I’ll try to explain what matters
to me.

Others will undoubtedly have different priorities but for me, it is
the ability to easily re-use libraries that come from the *nix side of
the Ruby community.

With regards to Windows libraries, as far as I see, apart from the
excellent work by Daniel B., Park H., Curt H. and a few
others, there is not nearly the same level of input from Windows
users.

Also, if I really need to program something using a Windows-specific
API that is only supported by MS tools, I use those MS tools.

I can’t really buy the performance arguments - if I were really
concerned with a 10% difference in performance between compilers, I
wouldn’t be using Ruby in the first place - I’d code it in C.

The performance difference I care about is programmer performance. I
found myself spending far too much time trying to get Ruby & all those
useful libs to compile under the most recent versions of VC++. It is
not because Curt can’t be bothered to upgrade that the One-Click is
still using VC6.

I agree with you that the maintainers of many of those parent libs
make no effort to accommodate the Win32 toolchain. Why should they?
They don’t use Windows. I seriously doubt whether bitching at them
will make any difference.

We develop on Windows and target both Windows and Linux. Two of my
developers work in Mac OS/X. I want our code to be portable and for
there to be as little impedance as possible in getting things to work
on all three platforms.

However, I can understand that others may have different points of
view depending on their requirements and I wouldn’t assume that ours
is the common case.

Perhaps we could spell out those requirements in this discussion so
they could be taken in to account?

Regards,
Sean

113

On Sat, 22 Jul 2006, Austin Z. wrote:

  1. I need to continue work on things that matter to me, which include
    PDF::Writer and my impending wedding.
  2. I am handing the communication with the VS team over to Curt as
    soon as I have a chance to pull everything together.
  3. I don’t need gsl.

fair enough and thanks for doing it (when you do).

I oppose the use of MinGW for the Ruby installer. Vehemently. It’s not the
right way, and will only complicate things for 64-bit Windows support (which
Vista will have right out of the box). The API support for MinGW is behind
and it doesn’t interface well with the newer parts of Windows because it’s
built on an outdated runtime that still has security issues.

i can’t comment here.

The problem isn’t the toolchain provided by the compiler at this point; it
is that Ruby’s toolchain isn’t sufficiently cross-platform (a la Perl’s
“perl Makefile.PL” or Python’s distutils) and needs to grow up so that you
don’t even have to think about this.

but no one has offered to do this work. with msys, someone’s already
done it
for us. i agree with you to some extent, but this is a matter of
expedience

  • what do we have now and what are people willing to create now. taking
    that
    into consideration shows that not one single windows developer has
    volunteered
    for a project like the one you suggest.

I am also not convinced that everything needs to be compiled with VS2005 to
make it work; only extensions and those libraries which do not provide an
alternative to the use of “errno” directly (they should be across API
calls).

see my post and the one to ruby-core. errno is just one such issue and,
since
no one can provide us with a list, we must assume there are more.

regards.

-a

114

On Sat, 22 Jul 2006, Tanner B. wrote:

But I also know that today, in under 10 minutes I download MSYS+MinGW + Ruby
Source, and had it compiled and running test scripts.

bingo.

you could do the same with gsl. we could more open source projects
compiled
today than vc++ could in a year.

-a

115

Lothar S. wrote:

A 77MB toolchain is extremely heavy.

Ummm… Installed, Microsoft’s is 1,650MB on my system. MSYS is 206MB.

116

On Sat, 22 Jul 2006, Austin Z. wrote:

No, Ara, it’s not a language feature. It’s something that can be done, but
you’ll note that Ruby doesn’t ship with a compiler on any other platform.

And don’t tell me that that’s because those other platforms include
compilers – you don’t put a compiler on a real production machine.

[OT]

that’s a matter of taste - we certainly do - quite a bit of our stuff
compiles
stuff on the fly. we even load shared memory with pre-compiled tables
at
times - this is triggered when updates to a backing store are made. the
technique gives us fast lookups: 2 orders of magnitude faster than
berkeley
db, 1 order of magnitude faster that gperf generated hashes. as someone
who
manages two 30 linux clusters dedicated to doing fast near-realtime
production
(and research) commputations i assure you that compilers are often a
crucial
runtime component on those sytems where rt code generation (and this is
not
uncommon in science) exist.

A C/C++ compiler is wholly separate from Ruby and must be treated as such.

agreed - but the ability to find and use it (along with other tools like
install-sh or ar) is. just like the ability of certain ruby libs to use
the
network, by removing the thing it uses one can say you’ve broken that
ruby
capability.

regards.

-a

117

Hello Tanner,

TB> What happens when VC2k5 goes the way of VC6? What happens when we
can no
TB> longer acquire VC2k5 and Microsoft has moved on to their new
VC2k7fx3
TB> product, with new features, new tool chain, and different
compatibility
TB> problems? How long until MS changes the licensing, or distribution
of their
TB> toolchain in such a way that we have to move to either an open
source
TB> option, or to the newest MS provided solution? 6 months? A year? 3
years?
TB> We don’t know, and we can’t do anything to stop them.

How long until we have a maintainer dispute in the MinGW team? If this
happens we can move on. A new installer version will come at least about
every year, maybe 6 month. So we can change. It’s not something we write
in stone.

And this decision is also a little enforcement to the extension
maintainers
to provide a msvc compatible build process.

The problems and danger are comming IMHO from the gnu/gcc side of
darkness.

Ruby still suffers in plattform independence because to much is done
on unix boxes and ignorance about windows issues among the developers
is high. The “win32.c” already has to much code that shows that people
don’t have any understanding about the windows plattform
(take “Kernel::system” for example).

TB> The current MSYS+MinGW can’t be pulled out from underneath us, ever.
I
TB> greatly dislike the idea of relying on ANY non-open product to
provide the
TB> prodominent Windows distribution of Ruby. You obviously disagree,
and
TB> that’s completely within your right to do. I also know you’ve put
in a lot
TB> of work to try to get VC2k5 to compile Ruby and its dependencies,
which is a
TB> great thing, and many of us appreciate the choice that that work can
bring.
TB> But I also know that today, in under 10 minutes I download
MSYS+MinGW + Ruby
TB> Source, and had it compiled and running test scripts.

You see we already have this problem that the Ruby Core team is not
keeping both major systems upto date. I would really start to worry if
we
now also move to a gcc compiler. This is not good.

118

Hello Christian,

CN> It’s getting time the Ruby “compiler”/runtime-environment is
rewritten
CN> in Ruby. :^)

Let us wait 20 years with this until we have the ultra fast quantum
computer. But then maybe an imperative language like ruby is also not
used anymore.

I’m really scared about seeing the performance of a ruby parser written
in ruby.

119

“Austin Z.” [email protected] writes:

other platform. And don’t tell me that that’s because those other
platforms include compilers – you don’t put a compiler on a real
production machine.

It’s getting time the Ruby “compiler”/runtime-environment is rewritten
in Ruby. :^)

120

On Friday, July 21, 2006, at 6:15 AM, Alex Y. wrote:

Not to throw stones or anything, but are these positions backed by a
technical knowledge, or political opinions? If technical, then what are
the arguments?

I know which I’d prefer, and I’m pretty sure I know which is the more
generally useful of the two, but I’ve kept out of the discussion so far
because I’m not an extension distributor who would be directly affected.

I recently started a new job in a Windows based lab (having been in Mac
only labs for the past decade) and I have some C functions that I need
to expose to Ruby. Obviously there’s some major windows development
learning curve for me as well, but I can create extensions using the
MinGW setup and have so far failed to do so (despite many, many hours of
effort) with the MS toolchain.

And I started this project with the belief that it would be best to go
with Microsoft’s tools and spent many hours over several days on that
before switching over to the mingw setup - which I was able to work
through in under a day. I readily admit to not being any kind of a
ninja/guru programmer, but for me, mingw proved to be usable while I
could not for the life of me figure it all out with Microsoft’s tools.

So, again, +1 MinGW.

-r