wxruby users - Apr 2004 - RubyGems and wxRuby

Kevin, were you planning to do a linux tarball or RPM for 0.3 before
focusing on the SWIG version? I think its important for many obvious
reasons, but I''ll just mention the one that prompted me to write this
email.

In the long term, I''d like to see wxRuby become the standard GUI
toolkit for
ruby, and I am simultaneously working several fronts to help make that
happen. My pressing concern is with the RubyGems browser that I am
developing as a wxRuby GUI application.

The RubyGems project has morphed into much more that a simple container for
ruby libraries and applications, and now encompasses features found in
apt-get and gentoo''s portage. RubyGems rocks -- big time! It increases
ruby''s easy-of-use by an order of magnitude, and I believe that it will
be
one of the core pieces that will help propel Ruby to the next level
(whatever that means).

One of the keys to RubyGem''s success is its utter ease-of-use. The
RubyGems
Browser will be the first highly visible showcase for wxRuby. Installing and
using the RubyGems Browser has to be as easy and simple as installing and
using RubyGems itself. Anything less will be a failure and reflect poorly on
wxRuby as a viable choice for GUI applications.

It really won''t be acceptable to ask user of the RubyGems Browser build
wxWidgets and wxRuby from source code before they can run the RubyGems
Browser.

So if you were already planning on making linux binaries, great! If not, I
hope I''ve convinced you to change your mind.

Curt

PS
  Once we have binary builds for 0.3 on Windows, Linux, and the Mac,
I''m
going to take a stab at packing it up as a RubyGem that will automatically
install the proper platform-specific binary.

Curt Hibbs wrote:
> Kevin, were you planning to do a linux tarball or RPM for 0.3 before
> focusing on the SWIG version? I think its important for many obvious
> reasons, but I''ll just mention the one that prompted me to write
this email.
I actually wasn''t planning to, but I can. Prior to rubygems, I viewed 
having .RPM and .DEB files as being more valuable than a raw Linux 
tarball. But if the raw tarball works as a gem, the other formats become 
far less important.
> RubyGems rocks -- big time! It increases
> ruby''s easy-of-use by an order of magnitude, and I believe that it
will be
> one of the core pieces that will help propel Ruby to the next level
> (whatever that means).
I agree. I have only installed one gem so far (rake), but so far I like 
what I have seen of rubygems. I definitely want wxRuby to be a gem.
>   Once we have binary builds for 0.3 on Windows, Linux, and the Mac,
I''m
> going to take a stab at packing it up as a RubyGem that will automatically
> install the proper platform-specific binary.
Ok. I''m a bit nervous posting the Linux wxRuby tarball, because I
don''t
know if it will have dependencies specific to Debian or my system. I 
guess we''ll find out. I haven''t yet thought through what the
tarball
should actually contain. If you know of any rubygems advice in that 
area, please point me to it.

I would love to help test the gem when you have it ready.

Kevin

On Apr 15, 2004, at 10:58 PM, Kevin Smith wrote:
>>   Once we have binary builds for 0.3 on Windows, Linux, and the Mac, 
>> I''m
>> going to take a stab at packing it up as a RubyGem that will 
>> automatically
>> install the proper platform-specific binary.
>
> Ok. I''m a bit nervous posting the Linux wxRuby tarball, because I 
> don''t know if it will have dependencies specific to Debian or my 
> system. I guess we''ll find out. I haven''t yet thought
through what the
> tarball should actually contain. If you know of any rubygems advice in 
> that area, please point me to it.
A RubyGem can also be a (C) source RubyGem where that source is built 
upon install (assuming you use extconf.rb).

Does WxRuby use extconf.rb?...if so...it should be quite easy.

If you need to pass parameters to the extconf.rb:

ruby wxruby.gem --force -- --with-wxwidgets-dir=/usr/local

everything past the -- is sent to the extconf.rb file.

This only works for Ruby extensions, they would need wxWidgets already 
installed...

Of course on win32, it should just be a binary (as Curt is likely to 
provide).

-rich

Kevin Smith wrote:
>
> Curt Hibbs wrote:
> > Kevin, were you planning to do a linux tarball or RPM for 0.3 before
> > focusing on the SWIG version? I think its important for many obvious
> > reasons, but I''ll just mention the one that prompted me to
> write this email.
>
> I actually wasn''t planning to, but I can. Prior to rubygems, I
viewed
> having .RPM and .DEB files as being more valuable than a raw Linux
> tarball. But if the raw tarball works as a gem, the other formats become
> far less important.
[snip]
> Ok. I''m a bit nervous posting the Linux wxRuby tarball, because I
don''t
> know if it will have dependencies specific to Debian or my system. I
> guess we''ll find out. I haven''t yet thought through what
the tarball
> should actually contain. If you know of any rubygems advice in that
> area, please point me to it.
Packaging as a RubyGem serves the same function as an RPM (or windows
installer), except that its cross-platform. Exactly how this works with
binaries I''m not sure (I''ll have to ask the RubyGems core
team). But we
wouldn''t have to actually release a tarball, I would just need the
binaries
to construct the RubyGem.
> I would love to help test the gem when you have it ready.
Yeah, we should all test it as I''m sure we will be breaking new ground
with
a multi-platform binary (is that an oxymoron?).

Curt

Richard Kilmer wrote:
>
> On Apr 15, 2004, at 10:58 PM, Kevin Smith wrote:
>
> >>   Once we have binary builds for 0.3 on Windows, Linux, and the
Mac,
> >> I''m
> >> going to take a stab at packing it up as a RubyGem that will
> >> automatically
> >> install the proper platform-specific binary.
> >
> > Ok. I''m a bit nervous posting the Linux wxRuby tarball,
because I
> > don''t know if it will have dependencies specific to Debian or
my
> > system. I guess we''ll find out. I haven''t yet
thought through what the
> > tarball should actually contain. If you know of any rubygems advice in
> > that area, please point me to it.
>
> A RubyGem can also be a (C) source RubyGem where that source is built
> upon install (assuming you use extconf.rb).
>
> Does WxRuby use extconf.rb?...if so...it should be quite easy.
>
> If you need to pass parameters to the extconf.rb:
>
> ruby wxruby.gem --force -- --with-wxwidgets-dir=/usr/local
>
> everything past the -- is sent to the extconf.rb file.
>
> This only works for Ruby extensions, they would need wxWidgets already
> installed...
This is what I would want to avoid.

I''m not sure what Kevin did for Linux in the past, but for Windows I
built
wxWidgets as a static library so that when I created wxRuby.so it contained
everything -- nothing else to install, no external dependencies. I''m
pretty
sure the Mac version is built the same way.

So Rich, my question to you is this: Can I construct a RubyGem such that I
can have several alternative, pre-built binaries, and get the correct one
installed for the user''s platform?

Curt

adding rubygems list...comments at end...

On Apr 15, 2004, at 11:15 PM, Curt Hibbs wrote:
> Richard Kilmer wrote:
>>
>> On Apr 15, 2004, at 10:58 PM, Kevin Smith wrote:
>>
>>>>   Once we have binary builds for 0.3 on Windows, Linux, and the
Mac,
>>>> I''m
>>>> going to take a stab at packing it up as a RubyGem that will
>>>> automatically
>>>> install the proper platform-specific binary.
>>>
>>> Ok. I''m a bit nervous posting the Linux wxRuby tarball,
because I
>>> don''t know if it will have dependencies specific to Debian
or my
>>> system. I guess we''ll find out. I haven''t yet
thought through what
>>> the
>>> tarball should actually contain. If you know of any rubygems advice
>>> in
>>> that area, please point me to it.
>>
>> A RubyGem can also be a (C) source RubyGem where that source is built
>> upon install (assuming you use extconf.rb).
>>
>> Does WxRuby use extconf.rb?...if so...it should be quite easy.
>>
>> If you need to pass parameters to the extconf.rb:
>>
>> ruby wxruby.gem --force -- --with-wxwidgets-dir=/usr/local
>>
>> everything past the -- is sent to the extconf.rb file.
>>
>> This only works for Ruby extensions, they would need wxWidgets already
>> installed...
>
> This is what I would want to avoid.
>
> I''m not sure what Kevin did for Linux in the past, but for Windows
I
> built
> wxWidgets as a static library so that when I created wxRuby.so it 
> contained
> everything -- nothing else to install, no external dependencies.
I''m
> pretty
> sure the Mac version is built the same way.
This is fine, assuming everyone''s linux runs the same binary.  This is 
less
of an issue for both OS X and Win32 due to the control of the 
OS/Libraries.
>
> So Rich, my question to you is this: Can I construct a RubyGem such 
> that I
> can have several alternative, pre-built binaries, and get the correct 
> one
> installed for the user''s platform?
>
> Curt
>
>
I don''t think you want to have a single gem with every binary in it,
but
a gem binary for each platform.  Is that right?  I believe we have this
capability now...Chad???

I know in the Gem spec you can specify the platform (win32, etc).  The
question is how does the installer deal with multiple available gems
(of the same name) but of different platforms.  Chad and I talked of
this, but I don''t know the state of the implementation.

-rich

Curt Hibbs wrote:
> I''m not sure what Kevin did for Linux in the past, but for Windows
I built
> wxWidgets as a static library so that when I created wxRuby.so it contained
> everything -- nothing else to install, no external dependencies.
I''m pretty
> sure the Mac version is built the same way.
I have been building Linux stuff with nothing statically linked. I 
assume Gour set up the gentoo emerge script that way, also. As long as 
you are within portage/apt/rpm, dynamic linking is a big win, with none 
of the dependency problems of dll-hell.

But as a gem, it would probably make sense to link in the wxWidgets 
stuff, and its dependencies (GTK, etc). Not the standard C and C++ libs, 
though, nor libruby itself. Hmm. Last time I tried to do static linking 
I couldn''t get it to work. I''ll have to try again, I guess.

Kevin

Richard Kilmer wrote:
> A RubyGem can also be a (C) source RubyGem where that source is built 
> upon install (assuming you use extconf.rb).
> 
> Does WxRuby use extconf.rb?...if so...it should be quite easy.
Yes, currently it does.
> This only works for Ruby extensions, they would need wxWidgets already 
> installed...
I''m considering moving to rake[1] and want to make sure wxRuby would 
still work as a source gem if I did so. Are you considering having 
rubygems directly support rake?

If not, I should be able to write my own extconf.rb and make command 
that would do what they need to do. As long as rubygems just runs 
"extconf.rb" followed by "make". I hope you don''t
have any deep
dependencies on specific implementations of extconf.rb,

Kevin

[1] When I mentioned rake on the list a while ago, several people gave 
good reasons to stay with make. I am still undecided, but rake allowed 
me to get the wxruby-swig prototype working very quickly, with far less 
pain and confusion than make. I''ll only switch back to make if there
are
compelling reasons to do so.

Richard Kilmer wrote:
> 
> On Apr 15, 2004, at 11:15 PM, Curt Hibbs wrote:
> >
> > So Rich, my question to you is this: Can I construct a RubyGem such 
> > that I
> > can have several alternative, pre-built binaries, and get the correct 
> > one
> > installed for the user''s platform?
> >
> > Curt
> >
> >
> 
> I don''t think you want to have a single gem with every binary in
it, but
> a gem binary for each platform.  Is that right?  I believe we have this
> capability now...Chad???
Yes, having a separate gem for each platform would be best.
> I know in the Gem spec you can specify the platform (win32, etc).  The
> question is how does the installer deal with multiple available gems
> (of the same name) but of different platforms.  Chad and I talked of
> this, but I don''t know the state of the implementation.
I knew I might be pushing the envelop here!  :-)

Curt

Kevin Smith wrote:
>
> [1] When I mentioned rake on the list a while ago, several people gave
> good reasons to stay with make. I am still undecided, but rake allowed
> me to get the wxruby-swig prototype working very quickly, with far less
> pain and confusion than make. I''ll only switch back to make if
there are
> compelling reasons to do so.
I don''t recall the arguments, but I too like rake (even though I
haven''t yet
used it :-)). I can''t see anything wrong with moving to rake
(especially in
a RubyGem context).

Curt