On Thu, 20 Jul 2006, Curt H. wrote:
you did bundle MinGW + MSYS, it would add around 77MB.
Curt
i love this idea.
-a
On 7/19/06, Sean O’Halpin [email protected] wrote:
possible.
Curt
Ah yes but it’s in VC6 at the moment is it not? Which brings us round
full circle.
So what are your thoughts on MinGW vs MS VC2005 Express?Regards,
Sean
I need to go through all of the feedback and tally up the pros and cons.
But
my gut feeling is that MinGW is winning the race.
Curt
Curt H. wrote:
I need to go through all of the feedback and tally up the pros and
cons. But
my gut feeling is that MinGW is winning the race.
RMagick votes for MinGW.
Curt H. wrote:
The MinGW environment could be distributed with the One-Click Ruby
Installer
(which is a plus), but I believe the MS compiler would need to be
separately
downloaded and installed by the end user.Curt
Ah, but if the “environment” is really 77 MB, that would hurt … a lot
…
I’ve been thinking about the way R does it. Briefly, their main
development platform is Linux, and their main method of package
distribution is source. On Linux, a package with just R source is simply
downloaded from a repository, unpacked, checked, and then is executable.
Packages containing C, C++ or Fortran source are compiled at install
time. R itself is often built from source, although the common binary
formats (RPM, Debian, MacOS X) are supported. Building R from source on
a Linux system requires C/C++, Fortran, etc. It’s a straightforward
“configure; make; make check; make install” sequence.
On Windows, however, R is distributed as a one-click installer. And
packages are usually pre-compiled and installed from ZIP archives
downloaded from the repository. If you want to build packages from
source, you have to install an exact set of tools and follow an exact
procedure. Someone on the R project team does this for most of the
packages! And if you want to build R itself, you have to install even
more tools and follow even more exact procedures. Again, someone on the
R project team does this every time there’s a release, and in addition
daily for patched and development releases!!
Incidentally, like R and most of the library packages, the tools to
build R and the packages on Windows are all open source or at least
freely downloadable. I believe the only Microsoft dependency is to
compile help files, though I could be wrong about that.
My question is, “Would such a model (mostly open source, but everything
precompiled by someone for Windows,)” work for Ruby, Ruby’s gems and
other packages, and Ruby’s Windows users? I’ve lived with it for years
in the R world. It’s not my preferred modus operandi but it was tough
enough to get an open source tool like R “approved” in a corporate
Windows IT shop. The fact that R is a far better piece of software than
commercial packages with licenses costing multiple thousands of US
dollars didn’t matter. These people only see the risks.
So … is someone going to step up to the plate and pre-compile gems
that require C or some other language? This model seems to work for R;
would it work for Ruby? Rails?
fr Joel:
fr Mauricio:
> 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.)
voting: += 2
though, i would prefer for a separate bundle for the pack w included
compiler. if that is ok with Curt.
I need the plain binary for the users.
I need the binary+compiler for the developers (yes a ruby developers kit
as mauricio pointed).
kind regards and thanks for one-click
-botp
On 7/19/06, M. Edward (Ed) Borasky [email protected] wrote:
Ah, but if the “environment” is really 77 MB, that would hurt … a lot
“configure; make; make check; make install” sequence.Windows IT shop. The fact that R is a far better piece of software than
commercial packages with licenses costing multiple thousands of US
dollars didn’t matter. These people only see the risks.
That’s pretty much how it works today.
So … is someone going to step up to the plate and pre-compile gems
that require C or some other language? This model seems to work for R;
would it work for Ruby? Rails?
Binary, platform-specific RubyGems are already possible. FXRuby, for
example, is distributed this way.
Curt
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 S.
neotrivium.com - the swiss ruby shop
I need to go through all of the feedback and tally up the pros and
cons. But
my gut feeling is that MinGW is winning the race.
+1 for MinGW.
-r
On 7/20/06, Kaspar S. [email protected] wrote:
(extension X being available for mswin builds, but not mingw builds,
will
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.
Thanks for the conscise summary!
I really can’t add to that; I think your decision is a hard one to make
and
virtual machine. Requires close collaboration and some funding.
best regards,
Kaspar S.
The manpower issue is very real. Its difficult enough to find help with
one
compiler – two would be impossible. MinGW is still looking like the way
to
go, although I’m not yet ready to declare that without a little more due
consideration.
There is one major hole in the build processes for the one-click
installer
that I want to fix along with this compiler transition – tests for the
included extensions – there aren’t any. This needs to change. For each
included extension there needs to be at least a few basic automated
tests to
ensure that the extension is functioning properly. If anyone wants to
volunteer to help with this, please email me (curt at hibbs dot com) and
I’ll hold your name in reserve until I get to that point.
Curt
I was wondering if the toolchain could be built around rake?
rake is Ruby’s make, but you make ruby in (n)make?
There is one major hole in the build processes for the one-click
installer
Ryan R. wrote:
I need to go through all of the feedback and tally up the pros and
cons. But
my gut feeling is that MinGW is winning the race.+1 for MinGW.
-r
-1 for MinGW
+1 for VC
The O.-Click Ruby Installer’s build process is, in fact, controlled via
Rake. However, since the OCI is basically an aggregation of other
packages,
those packages are built with whatever tool he author of tht package
used
(which is called by the OCI’s rake file).
Curt
Reggie Mr wrote:
Ryan R. wrote:
+1 for MinGW.
-r
-1 for MinGW
+1 for VC
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.
Apologies for the noise.
Extension authors are free to use Rake if they choose.
Curt
I was rather hoping the Rake’s reach could extend to the be a compelling
platform for extension authors. Sort of get into the stream in place of
mkmf.
From: “Reggie Mr” [email protected]
MS needs to evolve also, do you expect MS to continue to enhance MS-DOS.
Since you asked… No. But MS-DOS is frightfully in need of
enhancement,
evolution, and (in non-mystical terms) intelligent design. Not that I
expect any of
that to occur. 
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++.
I’ll admit I used to agree. Back when ruby on Windows was built on
cygwin,
I used to run into weird problems like a compiled-in 256-meg RAM
allocation
limit, or such.
Back then, the choice between cygwin and VC++ seemed clear.
Now that I’m trying to write applications in ruby on Linux, OS X, and
Windows,
and am dealing with building non-standard extensions on Windows like
RMagick, math3d, OpenGL, freeglut, FTGL, OpenAL, ruby-gstreamer, I
really think it would be a time-saver to have a consistent
extension-build
toolchain between these platforms.
So even though my vote several years ago would have been for VC++,
It’s for MinGW/msys now.
Regards,
Bill
RM> -1 for MinGW
RM> +1 for VC
Some here
-1 for MingGW
+1 for VC
VC has still a much better optimizer then gcc, if you use it with care
about 10% faster, which today where CPU’s are not getting faster as
fast is still important.
MS it is keeping better capatibility. How many thousands of programms
were brocken by the (technically unnecessary) changes from 3.3 to 3.4.
MinGW always had problems with Windows specific new technology because
in the past - don’t know how the situation is now - they were not
allowed to use the windows header files directly.
A 77MB toolchain is extremely heavy.
Then look at the update frequency of MingW and components, i can use
MSVC for years without problems, but the release-often/release-too-early
sympthom of open source is a different beast.
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.
To cut a long story short: I don’t trust MinGW.
Lothar S. wrote:
fast is still important.
10% is a LOT! I’d like to see these numbers that proove 10%.
I’d be sure there is a difference but 10% is ridiculous.
MS it is keeping better capatibility. How many thousands of programms
were brocken by the (technically unnecessary) changes from 3.3 to 3.4.
And how close to the C++ spec was vc6? it was ABYSMAL! Its better in
vc2005.
A 77MB toolchain is extremely heavy.
It is not a 77mb download for mingw. I would also think ruby would only
need gcc-core, binutils and msys.
The VC++2005 Express is 474mb download
Then look at the update frequency of MingW and components, i can use
MSVC for years without problems, but the release-often/release-too-early
sympthom of open source is a different beast.
some people are still using gcc 2.9.5. whats your point? there is no
forced upgrade requirement.
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.
To cut a long story short: I don’t trust MinGW.
I smell a rat. Most of your complaints are bogus.
Doesnt microsofts license forbid redistribution of VC Express anyway?
-stu
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.pth
I don’t think that this is an issue. msvcrt.dll is nearly ubiquitous and
already present on virtually all Windows systems.
Curt
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.
pth