Supporting both ruby 1.8 and 1.9 in a compiled library

ruby-talk
1

Hi all,

I am a maintainer of the Ruby interface to a C++ library wrapped using
SWIG. Up until now I have only supported Ruby 1.8 but I'm now adding
support for Ruby 1.9. Are there any recommendations for how to allow
both compiled copies of this wrapped library to be on the load path
($RUBYLIB) given that the *.so files are different for 1.8 and 1.9?
(Some of my users will use 1.8 and others will use 1.9 but $RUBYLIB is
shared). I was thinking of my own solution similar to (module is "oa"):

oa.rb
oa/1.8/x86_64-linux/*.so
oa/1.9/x86_64-linux/*.so

And the oa.rb file will have custom code written to dispatch to one set
of the *.so files based on the Ruby version. Are there any better ways?
Sorry if this is a basic question... I could not find the answer by
doing some Internet searches.

I'd prefer to not use gems for this since I will not distribute it
online and Ruby 1.8 is not guaranteed to have rubygems installed (trying
to keep this as flexible and simple as possible).

Thanks in advance...

-James

···

--
Posted via http://www.ruby-forum.com/.

2

the better way: build your *.so twice, one for each version and put the
files in the vendor_ruby path

so require "yourname" does work for both and you does not need an extra
rb file

···

--
Posted via http://www.ruby-forum.com/.

3

James Masters wrote in post #1016122:

Hi all,

I am a maintainer of the Ruby interface to a C++ library wrapped using
SWIG. Up until now I have only supported Ruby 1.8 but I'm now adding
support for Ruby 1.9. Are there any recommendations for how to allow
both compiled copies of this wrapped library to be on the load path
($RUBYLIB) given that the *.so files are different for 1.8 and 1.9?
(Some of my users will use 1.8 and others will use 1.9 but $RUBYLIB is
shared). I was thinking of my own solution similar to (module is "oa"):

oa.rb
oa/1.8/x86_64-linux/*.so
oa/1.9/x86_64-linux/*.so

Perhaps you can take a look to rake-compiler:

Which provides what is called "fat-binaries" and version out the
directory of Ruby implementation using this technique.

The other approach is use the RbConfig::CONFIG["ruby_version"] which
will provide you the API compatibility version, so 1.8 for 1.8.6, 1.8.7
and 1.9.1 for Ruby 1.9.1, 1.9.2 and 1.9.3

And the oa.rb file will have custom code written to dispatch to one set
of the *.so files based on the Ruby version. Are there any better ways?
Sorry if this is a basic question... I could not find the answer by
doing some Internet searches.

I'd prefer to not use gems for this since I will not distribute it
online and Ruby 1.8 is not guaranteed to have rubygems installed (trying
to keep this as flexible and simple as possible).

Then you should use "setup.rb" which will install the compiled extension
in the platform specific folder, except for the versioned part.

Good luck,

···

--
Luis Lavena

--
Posted via http://www.ruby-forum.com/\.

4

Thanks for the responses so far.

Hans - I didn't mention that I do not have privileges to modify the ruby
installation... I'm a user in our system (not an admin) and need to
store the libraries in a location other than the ruby install.

Luis - good suggestions but I'm more focused on how to set it up so I
can access the libraries using the same $RUBYLIB (or an equivalent) for
both 1.8 and 1.9 as opposed to the steps related to
compiling/installing.

Thanks,
-James

···

--
Posted via http://www.ruby-forum.com/.

5

thats why gem is better, it manage that the stuff is installed into the
right file (even as user)
its also possible with only mkmf but very bad

and PS: 1.8 should die

···

--
Posted via http://www.ruby-forum.com/.

6

Hi James,
I had a similar problem to solve in the CDI project: https://code.zmaw.de/projects/cdi. You can register yourself and watch in the repository (https://code.zmaw.de/projects/cdi/repository/show/trunk/cdi/interfaces) or take a look into the tar ball https://code.zmaw.de/attachments/download/1537/cdi-1.5.1.tar.gz.
I did not use gem which might have been the better solution.

cheers
ralf