ruby, Windows support

Windows support

Author

Message

Daniel Carrer
#1 / 20

Windows support

Hello,

Suppose I write a Ruby module with some C code in it. This is no problem
under Unix, Linux and Mac, but it makes things harder under Windows. What
is the best way to support Windows?

On a related note:

1) Does Microsoft's Visual C++ provide a 'make' program?
If not, how can I get Ruby to compile C code automatically?

2) Does Cygwin or MinGW provide a 'make' and gcc that can be used like the
Linux ones?
What's the difference between Cygwin and MinGW? I ask because I could
have a note on the project website saying

"If you are running Windows you'll need to download ..."

Something like that would fix the Windows support problem.

3) What other C compilers should I support?

Thanks for the help.

--
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

Mon, 01 Aug 2005 04:40:35 GMT

Daniel Berge
#2 / 20

Windows support

Quote:

> Hello,

> Suppose I write a Ruby module with some C code in it. This is no problem
> under Unix, Linux and Mac, but it makes things harder under Windows. What
> is the best way to support Windows?

Buy VC++ 6.0 or later. Share .so files for folks who don't have (or can't
afford) VC++.

Quote:

> On a related note:

> 1) Does Microsoft's Visual C++ provide a 'make' program?

Yes, it's called nmake, and you can get it for free off the internet. It
also comes with VC++.

Quote:

> 2) Does Cygwin or MinGW provide a 'make' and gcc that can be used like the
> Linux ones?

If you build a windows app using cygwin, any machines that you want to run
your code on will also require cygwin. It's not an ideal solution.

Quote:

> 3) What other C compilers should I support?

You shouldn't need to worry about supporting specific compilers. Your C code
should compile irregardless of compiler, although I wouldn't use anything
other than VC++ for Windows, and gcc for *nix. The only other compiler
you'll generally hear of people using is Sun's C compiler, but it ain't free.

Hope that helps.

Regards,

Dan

--
a = [74, 117, 115, 116, 32, 65, 110, 111, 116, 104, 101, 114, 32, 82, 117, 98]
a.push(121, 32, 72, 97, 99, 107, 101, 114)
puts a.pack("C*")

Mon, 01 Aug 2005 05:02:05 GMT

Lyle Johnso
#3 / 20

Windows support

Quote:

> Suppose I write a Ruby module with some C code in it. This is no problem
> under Unix, Linux and Mac, but it makes things harder under Windows. What
> is the best way to support Windows?

I think the number one recommendation is to rovide precompiled binaries
for your Windows users, preferably in a standard Windows installer
executable.

Quote:

> On a related note:

> 1) Does Microsoft's Visual C++ provide a 'make' program?

Yes, but it's called "nmake". There are also some differences between
GNU make's Makefile format (rules, etc.) and Microsoft's -- not sure if
those differences are documented anywhere, though.

Quote:

> 2) Does Cygwin or MinGW provide a 'make' and gcc that can be used like the Linux ones?

Yes, both the Cygwin project and MinGW provide ports of GNU make.

Quote:

> What's the difference between Cygwin and MinGW?

For a brief description of MinGW, see:

http://www.rubygarden.org/ruby?MinGW

and of course the MinGW home page (http://www.mingw.org).

Quote:

> 3) What other C compilers should I support?

For Windows? Seems like those three should cover it.

Mon, 01 Aug 2005 05:15:06 GMT

Daniel Carrer
#4 / 20

Windows support

[snip]

Quote:

> > What is the best way to support Windows?

> Buy VC++ 6.0 or later. Share .so files for folks who don't have (or can't
> afford) VC++.

Well. I'm not going to go out and buy Windows and then buy VC++ just for
this. I have no interest in using Windows. I just want to suppor it.

Quote:

> > On a related note:

> > 1) Does Microsoft's Visual C++ provide a 'make' program?

> Yes, it's called nmake, and you can get it for free off the internet. It
> also comes with VC++.

Thanks. Does nmake come with a C compiler too?

Quote:

> > 3) What other C compilers should I support?

> You shouldn't need to worry about supporting specific compilers. Your C code
> should compile irregardless of compiler,

That's not what I meant by my question. I will defintelly write my code
in ANSI C. I am talking about getting my Ruby installer to call the right
program.

So, in my installer I would test to see if either "make" or "nmake" is
installed, and then I'd call the one available. Is that about it? Does
nmake also come with a compiler?

Thanks for your help.

--
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

Mon, 01 Aug 2005 05:21:34 GMT

Daniel Berge
#5 / 20

Windows support

I'm responding to both Daniel's and Lyle's responses here...

Quote:

> [snip]
> > > What is the best way to support Windows?

> > Buy VC++ 6.0 or later. Share .so files for folks who don't have (or can't
> > afford) VC++.

> Well. I'm not going to go out and buy Windows and then buy VC++ just for
> this. I have no interest in using Windows. I just want to suppor it.

I'm very confused. How could you ever guarantee that your code works on Windows
if you never test it ON Windows? The instant you #include a header file, you risk
portability issues, even between different flavors of *nix. Add the funky Windows
API peculiarities and it becomes almost impossible to write "one piece of code to
bind them all". There are things you can do within mkmf, or #ifdefs within your C
code, but the actual *behavior* of identical C functions can vary wildly from
platform to platform.

Quote:

> > > On a related note:

> > > 1) Does Microsoft's Visual C++ provide a 'make' program?

> > Yes, it's called nmake, and you can get it for free off the internet. It
> > also comes with VC++.

> Thanks. Does nmake come with a C compiler too?

No.

Quote:

>Yes, but it's called "nmake". There are also some differences between
>GNU make's Makefile format (rules, etc.) and Microsoft's -- not sure if
>those differences are documented anywhere, though.

There are issues with the nmake that came with VC++ 5.0 and earlier (and problems
with VC++ 5.0 itself), which is why I recommended VC++ 6.0 or later. I haven't
had any problems with it (yet). They are documented....somewhere (can't remember
where now).

Quote:

> > > 3) What other C compilers should I support?

> > You shouldn't need to worry about supporting specific compilers. Your C code
> > should compile irregardless of compiler,

> That's not what I meant by my question. I will defintelly write my code
> in ANSI C. I am talking about getting my Ruby installer to call the right
> program.

> So, in my installer I would test to see if either "make" or "nmake" is
> installed, and then I'd call the one available. Is that about it? Does
> nmake also come with a compiler?

You shouldn't need to test it yourself. *nix users know to use 'make', Windows
users know to use 'nmake'. Or at least, they *will* know because you'll tell them
in your INSTALL file, right? Or, if you really want to build programatically,
test using RUBY_PLATFORM.

However, you probably DON'T want to do build programatically, because then you
prevent folks from passing any options to (n)make (-B, -C, etc).

Quote:

>I think the number one recommendation is to rovide precompiled binaries
>for your Windows users, preferably in a standard Windows installer
>executable.

For extensions Lyle? Heck, I don't know how to support Install Shield, but even
if I did I would only use it for large packages and/or standalone apps, not small
extensions.

Providing individual .so files is easy enough, though I think you will need help
from the community to do this, unless you happen to have 95, 98, ME, 2000 and XP
all installed somewhere. Generally speaking, I'd worry about the NT side of
things first (NT 4, 2000, XP Pro), 98 second, 95 third and ME last.

Regards,

Dan

--
a = [74, 117, 115, 116, 32, 65, 110, 111, 116, 104, 101, 114, 32, 82, 117, 98]
a.push(121, 32, 72, 97, 99, 107, 101, 114)
puts a.pack("C*")

Mon, 01 Aug 2005 06:23:21 GMT

Daniel Carrer
#6 / 20

Windows support

Quote:

> I'm very confused. How could you ever guarantee that your code works
> on Windows if you never test it ON Windows?

I'm just implementing simple math algorithms. The only thing I am likely
to include is "ruby.h". It really should compile anywhere.

Ofcourse, I would *test* on Windows before I claim that it runs on
Windows. I'd probably send it to my brother in Canada to try it out. But
that would be a last step.

90% of my code is Ruby. I just want to use C to speed up a method here
and there.

Quote:

> The instant you #include a header file, you risk portability issues,
> even between different flavors of *nix.

For what I'm doing, Mac OS X, Linux and all Unix should be trivally
supported. Windows presents the only possible difficulty.

Quote:

> Add the funky Windows API peculiarities and it becomes almost
> impossible to write "one piece of code to bind them all".

I will stay away from any Windows-specific API.
If I write ANSI C and don't include anything, everything "should" be fine.
Right?

Quote:

> You shouldn't need to test it yourself. *nix users know to use 'make',
> Windows users know to use 'nmake'. Or at least, they *will* know
> because you'll tell them in your INSTALL file, right?

I was thinking that it would be neat to have a single "install.rb" which
would do everything. I'm trying to comeup with an easy-and-reliable
installer.

Quote:

> However, you probably DON'T want to do build programatically, because
> then you prevent folks from passing any options to (n)make (-B, -C, etc).

What do those options do?
Would it be ok to just grab Ruby's ARGV and pass it to (n)make?

--
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

Mon, 01 Aug 2005 06:43:33 GMT

Lyle Johnso
#7 / 20

Windows support

Responding to Daniel Berger's response to my response ;)

Quote:

> There are issues with the nmake that came with VC++ 5.0 and earlier (and problems
> with VC++ 5.0 itself), which is why I recommended VC++ 6.0 or later. I haven't
> had any problems with it (yet). They are documented....somewhere (can't remember
> where now).

I didn't mean to suggest that 'nmake' is broken or anything, just that
it has some different stuff that GNU make. Or, put another way, if you
take a Makefile that works with GNU make it may not work with nmake
without some tweaking. I now wish I could remember something more
specific; but since I can't, I'll just drop that issue ;)

Quote:

>>I think the number one recommendation is to rovide precompiled binaries
>>for your Windows users, preferably in a standard Windows installer
>>executable.

> For extensions Lyle? Heck, I don't know how to support Install Shield, but even
> if I did I would only use it for large packages and/or standalone apps, not small
> extensions.

OK, I'll agree with that (that doing a full-blown installer is overkill
for small extensions) ;)

Mon, 01 Aug 2005 07:19:45 GMT

nobu.nok..
#8 / 20

Windows support

Hi,

At Thu, 13 Feb 2003 05:40:35 +0900,

Quote:

> 1) Does Microsoft's Visual C++ provide a 'make' program?
> If not, how can I get Ruby to compile C code automatically?

Half yes.
# I call it Not-MAKE or {*filter*}-MAKE.

In 1.8, extension of mingw and mswin are binary compatible, so
you don't have to use VC++. In the fact, they are installed to
same directory.

Quote:

> 3) What other C compilers should I support?

Borland's complier is supported in 1.8 now. Take a glance at
lib/mkmf.rb.

--
Nobu Nakada

Mon, 01 Aug 2005 08:03:26 GMT

Hal E. Fulto
#9 / 20

Windows support

Quote:

----- Original Message -----

Sent: Wednesday, February 12, 2003 4:23 PM
Subject: Re: Windows support

> a = [74, 117, 115, 116, 32, 65, 110, 111, 116, 104, 101, 114, 32, 82, 117,
98]
> a.push(121, 32, 72, 97, 99, 107, 101, 114)
> puts a.pack("C*")

Daniel,

YACS - Yet Another Cool Sig.

What do you think of this one?

str = "aa tut Rnrehoec Jykusbrh"; srand 0
0.upto(999) {|i| x = rand(23); str[x,2] = str[x,2].reverse! }; puts str

Hal

Mon, 01 Aug 2005 08:13:54 GMT

Bill Kell
#10 / 20

Windows support

Quote:

> What do you think of this one?

> str = "aa tut Rnrehoec Jykusbrh"; srand 0
> 0.upto(999) {|i| x = rand(23); str[x,2] = str[x,2].reverse! }; puts str

LOL... :) Were you joking, Hal? Or is my 1.6.6 mswin32 possibly
using a different algorothm for rand than your version? I couldn't
understand the result... :(

Regards,

Bill

_=155813688791654835066064433267;while(_>0);p(((((y=_%28)>1)?63:32)+y).chr);_/=28;end

Mon, 01 Aug 2005 09:03:51 GMT

Hal E. Fulto
#11 / 20

Windows support

Quote:

----- Original Message -----

Sent: Wednesday, February 12, 2003 7:03 PM
Subject: Re: .sig - was Re: Windows support

> > What do you think of this one?

> > str = "aa tut Rnrehoec Jykusbrh"; srand 0
> > 0.upto(999) {|i| x = rand(23); str[x,2] = str[x,2].reverse! }; puts
str

> LOL... :) Were you joking, Hal? Or is my 1.6.6 mswin32 possibly
> using a different algorothm for rand than your version? I couldn't
> understand the result... :(

That's very interesting.

You didn't omit the srand, did you?

For me, it prints "Just another Ruby hacker" --
and the srand is supposed to make the randomizing
deterministic or predictable.

Maybe that's only true within versions and/or
platforms.

Hal

Mon, 01 Aug 2005 09:10:56 GMT

Bill Kell
#12 / 20

Windows support

Quote:

> > > str = "aa tut Rnrehoec Jykusbrh"; srand 0
> > > 0.upto(999) {|i| x = rand(23); str[x,2] = str[x,2].reverse! }; puts str

> > LOL... :) Were you joking, Hal? Or is my 1.6.6 mswin32 possibly
> > using a different algorothm for rand than your version? I couldn't
> > understand the result... :(

> That's very interesting.

> You didn't omit the srand, did you?

> For me, it prints "Just another Ruby hacker" --
> and the srand is supposed to make the randomizing
> deterministic or predictable.

> Maybe that's only true within versions and/or
> platforms.

I definitely included the srand.... Haven't checked the Ruby src;
but maybe it calls a platform-specifc rand?

Regards,

Bill

P.S. what it yields on 1.6.6/mswin32 for me is, "aeoneR t rurhachJtykubs" :)

Mon, 01 Aug 2005 09:32:32 GMT

Hal E. Fulto
#13 / 20

Windows support

Quote:

----- Original Message -----

Sent: Wednesday, February 12, 2003 7:32 PM
Subject: Re: .sig - was Re: Windows support

> > > > str = "aa tut Rnrehoec Jykusbrh"; srand 0
> > > > 0.upto(999) {|i| x = rand(23); str[x,2] = str[x,2].reverse! };
puts str

> > > LOL... :) Were you joking, Hal? Or is my 1.6.6 mswin32 possibly
> > > using a different algorothm for rand than your version? I couldn't
> > > understand the result... :(

> > That's very interesting.

> > You didn't omit the srand, did you?

> > For me, it prints "Just another Ruby hacker" --
> > and the srand is supposed to make the randomizing
> > deterministic or predictable.

> > Maybe that's only true within versions and/or
> > platforms.

> I definitely included the srand.... Haven't checked the Ruby src;
> but maybe it calls a platform-specifc rand?

> Regards,

> Bill

> P.S. what it yields on 1.6.6/mswin32 for me is, "aeoneR t rurhachJtykubs"

Well, I don't think it's platform-specific, as I'm
also on Windows:

ruby 1.7.3 (2002-11-17) [i386-mswin32]

Maybe version-specific? That's a tiny bit disturbing
if so...

Hal

Mon, 01 Aug 2005 09:40:10 GMT

Eric Hode
#14 / 20

Windows support

Quote:

> Well, I don't think it's platform-specific, as I'm
> also on Windows:

> ruby 1.7.3 (2002-11-17) [i386-mswin32]

> Maybe version-specific? That's a tiny bit disturbing
> if so...

rand() is probably implemented in terms of rand(3). On FreeBSD, 4 and 5
will have different versions of rand(), so this didn't work at all for
me.

--

All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

application_pgp-signature_part
< 1K Download

Mon, 01 Aug 2005 10:53:06 GMT

Page 1 of 2

[ 20 post ]

Go to page: [1] [2]