[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: One-Click Installer: MinGW? or VC2005?

Bill Kelly

7/18/2006 6:33:00 PM

From: "Curt Hibbs" <ml.chibbs@gmail.com>
>
> 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
18 Answers

Tim Hunter

7/19/2006 1:59:00 AM

0

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

Austin Ziegler

7/21/2006 3:20:00 PM

0

On 7/18/06, Bill Kelly <billk@cts.com> wrote:
> 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
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Ara.T.Howard

7/21/2006 3:44:00 PM

0

Ara.T.Howard

7/21/2006 5:30:00 PM

0

Lothar Scholz

7/21/2006 6:52:00 PM

0

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.


--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ru...
CTO Scriptolutions Ruby, PHP, Python IDE 's

greg.kujawa

7/22/2006 1:22:00 AM

0


Lothar Scholz wrote:
>
> 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).
>

I agree with this assertion. In my world I prefer to use Ruby for most
tasks that I take up. But the handful of times I specifically abandon
Ruby for Python is solely due to the fact that my ActiveState Python
install under Windows doesn't hold me back from installing add-on
libraries. So if I can't get something to work under Ruby in Windows
then I just grab the equivalent Python libraries and use Python
instead.

It's usually as simple as running 'python setup.py' from the command
line or even executing an prepacked installation that does the job. No
tooling around with editing makefiles, tweaking the mkmf.rb, setup.rb,
install.rb, etc. as in the case with certain Ruby libraries. As a
language I don't prefer Python but I am familiar enough with it to do
what needs to be done. But while I'm doing it I lament the fact that
I'd rather be doing it in Ruby.

While there is a long thread debating Ruby interpreter performance, to
me the main things I see that perhaps are major drawbacks to Ruby truly
hitting the "big time" are:

1) Obvious lean toward Unix platforms and lack to true cross platform
compatibility in the Windows world.

2) Lack of well documented add-on libraries in certain cases. If you
comment your code well enough and syntactically correct enough just run
RDoc and include this in your package download.

3) Need for targeting embedded devices. From cell phones to PDA's to
smartphones there are lots of cutting edge projects which Ruby could
help expose how truly easy and fun programming them could be. But it
doesn't seem as if there's an overwhelming acknowledgement of this in
the Ruby community as a whole.

A little OT from the subject of mingw versus msvc, but my $0.02
nonetheless.

M. Edward (Ed) Borasky

7/22/2006 2:33:00 AM

0

gregarican wrote:
> 3) Need for targeting embedded devices. From cell phones to PDA's to
> smartphones there are lots of cutting edge projects which Ruby could
> help expose how truly easy and fun programming them could be. But it
> doesn't seem as if there's an overwhelming acknowledgement of this in
> the Ruby community as a whole.
>
I don't really like this idea. I find "live handheld programming" a
frustrating experience. Without a readable screen and a usable keyboard,
no matter how much RAM or flash memory a handheld has, it's basically
just a PIM/PDA/expensive calculator.

The last handheld I owned that I considered programmable was the
HP-100LX. This had DOS 5.0, a small but readable 80x25 screen and a
small but usable keyboard. It would run Forth, DOS Perl 4, Derive and
just about anything that would run under DOS. And it had a great PIM/PDA
built in as well as Lotus 1-2-3 2.4.

I've got a Sharp Zaurus 6000, BTW. Supposedly it runs Maxima and it has
a nice screen, but the keyboard is tiny. It's a tad big for a pocket,
but it's the closest thing I've found to the HP-100LX.

There's a *reason* people use SDKs to program small devices. I don't see
the point of a Ruby interpreter in anything without a real keyboard.

M. Edward (Ed) Borasky

7/22/2006 3:01:00 AM

0

gregarican wrote:
> I agree with this assertion. In my world I prefer to use Ruby for most
> tasks that I take up. But the handful of times I specifically abandon
> Ruby for Python is solely due to the fact that my ActiveState Python
> install under Windows doesn't hold me back from installing add-on
> libraries. So if I can't get something to work under Ruby in Windows
> then I just grab the equivalent Python libraries and use Python
> instead.
>
Hmmm ... now it's starting to make sense. There's ActiveState Python,
Perl and Tcl, CygWin Python, Perl and Tcl, and IIRC there are "native
Windows builds" from the appropriate open source community for these
three scripting languages.

There's a "native Windows build" of Ruby -- the one-click installer. And
there's CygWin Ruby. But so far, ActiveState hasn't built a Ruby. They
support Ruby in their Komodo IDE. Anyone here have a clue why there
isn't an ActiveState Ruby?

Hal E. Fulton

7/22/2006 3:01:00 AM

0

M. Edward (Ed) Borasky wrote:
> gregarican wrote:
>
>> 3) Need for targeting embedded devices. From cell phones to PDA's to
>> smartphones there are lots of cutting edge projects which Ruby could
>> help expose how truly easy and fun programming them could be. But it
>> doesn't seem as if there's an overwhelming acknowledgement of this in
>> the Ruby community as a whole.
>>
>
> I don't really like this idea. I find "live handheld programming" a
> frustrating experience. Without a readable screen and a usable keyboard,
> no matter how much RAM or flash memory a handheld has, it's basically
> just a PIM/PDA/expensive calculator.
>
> The last handheld I owned that I considered programmable was the
> HP-100LX. This had DOS 5.0, a small but readable 80x25 screen and a
> small but usable keyboard. It would run Forth, DOS Perl 4, Derive and
> just about anything that would run under DOS. And it had a great PIM/PDA
> built in as well as Lotus 1-2-3 2.4.
>
> I've got a Sharp Zaurus 6000, BTW. Supposedly it runs Maxima and it has
> a nice screen, but the keyboard is tiny. It's a tad big for a pocket,
> but it's the closest thing I've found to the HP-100LX.
>
> There's a *reason* people use SDKs to program small devices. I don't see
> the point of a Ruby interpreter in anything without a real keyboard.
>

I see your point. (I had the 200LX, by the way. What a sweet machine.)

But to me, the point is being able to *run* programs on the handheld --
something I'd love to do. I don't mind doing the development on the
desktop as long as I can run the result in the palm of my hand.

Ruby runs on the Zaurus, right? I grant you might not like coding and
debugging on it, but wouldn't you like to run your own custom apps on it
written in Ruby? I would.


Hal

M. Edward (Ed) Borasky

7/22/2006 3:13:00 AM

0

Hal Fulton wrote:
> I see your point. (I had the 200LX, by the way. What a sweet machine.)
>
> But to me, the point is being able to *run* programs on the handheld --
> something I'd love to do. I don't mind doing the development on the
> desktop as long as I can run the result in the palm of my hand.
>
> Ruby runs on the Zaurus, right? I grant you might not like coding and
> debugging on it, but wouldn't you like to run your own custom apps on it
> written in Ruby? I would.
I have to assume Ruby will run on the Zaurus, since gcc can build for
it. Incidentally, the "native" Zaurus GUI is QT. Now if QTRuby runs on
the Zaurus, *that's* interesting. Still, these days I'm more a
*collector* of handhelds than a user. :)