On 7/19/06, M. Edward (Ed) Borasky [email protected] wrote:
I have two choices VS2005 Express and MinGW. What I really want to
option to install a toolset for building extensions if the user doesn’t
already have that toolset. When I built the LyX editor on Windows, it
pointed me to URLs for all of the things I needed (MikTeX, Python, etc.)
That makes a lot of sense for LyX; MiKTeX is huge. But I would have
preferred as much of the toolset bundled.
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
Curt H. 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!).
Mauricio F. 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.)
On 7/19/06, Kevin W. [email protected] wrote:
(as
recompiled to work smoothly with any other.
- 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!).
Wikipedia has a good description:
MinGW - Wikipedia
Curt
On 7/19/06, Joel VanderWerf [email protected] wrote:
possible with VC?
–
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
This is a very good point (both Mauricio’s and yours). Its an angle that
I
had not thought of and could be a major plus.
Curt
On 7/18/06, Mauricio F. [email protected] wrote:
A “Ruby devel. kit” (in a similar spirit as Instant
Rails) including MSYS+MinGW is at least conceivable
+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, [email protected] [email protected] wrote:
that’s odd - i installed and compiled straight away… i’m at an airport now
but it actually wrote up what i did - i’ll dig it out when i get back. in any
case i assure you it can be done… make sure you’ve got mingw installed
correctly and do someting like
./configure --prefix=/c/usr/local && make && make install
good luck.
Please do post how you got this to work when you are back.
The first thing I did was download and install MSYS 1.0.10. This seems
to have worked fine.
Next, I downloaded the MinGW installer version 5.03 and ran it, and
asked it to download and install the “Current” release (which
included, among other things, gcc-3.4.2 I think). When that was done,
I grabbed the standard ruby-1.8.4.tar.gz, unpacked it, and did
“./configure”, followed by “make”. It bombed while compiling the very
first file, with errors about “redefinition of struct timezone” and
other types.
I’ve just uninstalled MinGW, and am going to start over again with the
“Candidate” release (which is based on gcc-3.4.5). We’ll see if that
goes any better…
Lyle J. wrote:
[…]
I’ve just uninstalled MinGW, and am going to start over again with the
“Candidate” release (which is based on gcc-3.4.5). We’ll see if that
goes any better…
I don’t think so, but this might help:
$ diff ruby-1.8.4/win32/win32.h.orig ruby-1.8.4/win32/win32.h
154,159d153
< #ifdef MINGW32
< struct timezone {
< int tz_minuteswest;
< int tz_dsttime;
< };
< #endif
203,204c197,200
< extern int link(char *, char *);
< extern int gettimeofday(struct timeval *, struct timezone *);
extern int link(char *, char *);
#ifndef MINGW32
extern int gettimeofday(struct timeval *, struct timezone *);
#endif
$ diff ruby-1.8.4/win32/win32.c.orig ruby-1.8.4/win32/win32.c
2536c2536
< #include <sys/timeb.h>
#include <sys/timeb.h>
2537a2538
#ifndef MINGW32
2558a2560
#endif
well, I’m not very used to this tools, how do i get a more
readable output ?
cheers
Simon
On 7/19/06, Lyle J. [email protected] wrote:
first file, with errors about “redefinition of struct timezone” and
other types.
I’ve just uninstalled MinGW, and am going to start over again with the
“Candidate” release (which is based on gcc-3.4.5). We’ll see if that
goes any better…
Hi Lyle,
I installed MinGW Current (MinGW-5.0.3) first, then
MSYS-1.0.11-2004.04.30-1, downloaded and unpacked ruby stable snapshot
(ftp://ftp.ruby-lang.org/pub/ruby/stable-snapshot.tar.gz), fired up
MSYS, entered this:
./configure --prefix=c:/ruby-mingw --enable-shared && make && make
install
Waited about 5-10 mins.
Back at Windows command prompt:
cd \ruby-mingw\bin
ruby -v
ruby 1.8.5 (2006-07-18) [i386-mingw32]
Good luck!
Regards,
Sean
On 7/19/06, Sean O’Halpin [email protected] wrote:
cd \ruby-mingw\bin
ruby -v
ruby 1.8.5 (2006-07-18) [i386-mingw32]
Good luck!
Thanks, Sean! I will add this to my list of experiments to try. I’m
currently trying to build Ruby 1.8.4 using the patches for
win32/win32.{c,h} provided by Simon Kroger (and those seem to work,
BTW).
Sean O’Halpin wrote:
On 7/18/06, Mauricio F. [email protected] wrote:
A “Ruby devel. kit” (in a similar spirit as Instant
Rails) including MSYS+MinGW is at least conceivable
+1 for this idea - a one-click binary installer and a one-click
build-from-source-kit installer would be great.
Regards,
Sean
I would love a one click installer that would include a
minimal own compiler tool chain and ruby + all standard
extensions as source code. It could build them (optimized
for the actual hardware) during the installation process.
All the gems that don’t have a binary version would just
work on such a system… well i guess I’m dreaming.
How big would such a packet be?
cheers
Simon
On 7/19/06, Simon Kröger [email protected] wrote:
I don’t think so, but this might help:
It does! Thanks for the patches, Simon. Based on Sean’s response I’m
guessing that this problem has been addressed in Ruby 1.8.5.
On 7/19/06, Simon Kröger [email protected] wrote:
Sean
cheers
Simon
Its more likely that the one-click installer would continue to be a
binary
distribution (with binary extensions), but with an compiler toolchain
that
allows users to build additional extensions from source or, even better,
provides a known target RubyGems packagers to create gems that require
compilation.
Curt
How about a “extension compiler toolchain” binary gem?
Curt H. wrote:
Its more likely that the one-click installer would continue to be a
binary
distribution (with binary extensions), but with an compiler toolchain
that
allows users to build additional extensions from source or, even better,
provides a known target RubyGems packagers to create gems that require
compilation.
Curt
Curt H. wrote:
Its more likely that the one-click installer would continue to be a binary
distribution (with binary extensions), but with an compiler toolchain that
allows users to build additional extensions from source or, even better,
provides a known target RubyGems packagers to create gems that require
compilation.
Curt
I’m just curious, why would you distribute binaries if you have to
provide
the compiler toolchain anyway?
(if we had a build farm, that would be another story)
cheers
Simon
On 7/19/06, Simon Kröger [email protected] wrote:
Curt
I’m just curious, why would you distribute binaries if you have to provide
the compiler toolchain anyway?
Install time, and consistency, and package size come to mind. I can
drop
the One Click on an older machine and have a ruby app running in a
matter of
minutes. If I was to have to compile ruby, all the extensions included
in
the one click (which would also mean having the headers for openssl,
mysql,
tk, and all the other great things that are included), I’d never get the
thing installed on an older machine. Binaries aren’t going to go away,
but
this DOES allow for some of the more aggressive extensions, ruby2c,
ruby-inline, ruby2extension, AND it allows the distributors of those
packages to be able to target a specific compiler/toolchain for windows.
(if we had a build farm, that would be another story)
On Wed, 19 Jul 2006, stu wrote:
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…
i’ve posted this as long as a year ago - but here’s a simple patch to
the
‘gem’ command that allows exactly this. usage is like
gem install bindir=/my/bin/dir/bin foobar
also, note that if you’re ever installing via install.rb or setup.rb you
can
always clobber rbconfig values in place using something like
ruby -r rbconfig -e’ Config::CONFIG[“KEY”] = “VAL”; load ARGV.shift
’ ./install.rb
here’s the patched gem command:
#!/usr/bin/env ruby
require ‘rubygems’
Gem.manage_gems
required_version = Gem::Version::Requirement.new(">= 1.8.0")
unless required_version.satisfied_by?(Gem::Version.new(RUBY_VERSION))
puts “Expected Ruby Version #{required_version}, was #{RUBY_VERSION}”
exit(1)
end
We need to preserve the original ARGV to use for passing gem options
to source gems. If there is a – in the line, strip all options after
it…its for the source building process.
args = !ARGV.include?("–") ? ARGV.clone : ARGV[0…ARGV.index("–")]
munge rbconfig from any command line or environment kv pair
kvs = []
re = %r/^ \s* ([^=\s]+) \s* = \s* ([^\s]+) \s* $/x
args.delete_if{|arg| (m = re.match(arg)) and (kvs << m.to_a.last(2))}
ENV::each{|k,v| (k =~ %r/^GEM_/) and (kvs << [k.delete(‘GEM_’), v])}
p kvs
unless kvs.empty?
require ‘rbconfig’
kvs.each{|k,v| Config::CONFIG[k] = v}
end
Gem::GemRunner.new.run(args)
-a
On 7/19/06, Sean O’Halpin [email protected] wrote:
provides a known target RubyGems packagers to create gems that require
cheers
and tweaks, etc. that have been used to create the one-click binary
version that you’d want in the developer version (i.e. a way to
reproduce exactly a copy of Curt’s development environment :). But if
you did bundle MinGW + MSYS, it would add around 77MB.
Regards,
Sean
At 77MB, it would have to be an optional add-on.
For those intrepid souls who want to build the one-click installer
distro
from source, it is itself an open source project, so that is entirely
possible.
Curt
On 7/19/06, Simon Kröger [email protected] wrote:
I’m just curious, why would you distribute binaries if you have to provide
the compiler toolchain anyway?
(if we had a build farm, that would be another story)
cheers
Simon
Hi Simon,
I was suggesting two installers - one for those who just want an easy
no-fuss one-click binary installer with everything on (the majority)
and one for extension developers who need a reference environment
against which to build extensions. You don’t need the MinGW + MSYS
environment bundled - you can get that off the net - it’s the patches
and tweaks, etc. that have been used to create the one-click binary
version that you’d want in the developer version (i.e. a way to
reproduce exactly a copy of Curt’s development environment :). But if
you did bundle MinGW + MSYS, it would add around 77MB.
Regards,
Sean
On 7/19/06, Curt H. [email protected] wrote:
At 77MB, it would have to be an optional add-on.
Indeed! 
For those intrepid souls who want to build the one-click installer distro
from source, it is itself an open source project, so that is entirely
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