Bug 981

Francois,

Thanks for the patch. I have had amarok patches for quite a while:

http://humanreadable.nfshost.com/trinity/patches/amarok/amarok-ruby19-cmake.diff
http://humanreadable.nfshost.com/trinity/patches/amarok/amarok-ruby19.diff

The challenge with patching amarok (and tdebindings, koffice, etc.) is being one-way. Several days ago I posted to the developer's mail list asking for help how to add ruby version checks in the patches. The reason is some people still use ruby 1.8.x. The current patch proposal (my patches too) only supports version 1.9.x. Currently I apply my patches by determing the ruby version with my build script. That approach is stop-gap and only helps me. A method is needed to determine the ruby version within the source code to apply the updated ruby changes only when ruby 1.9 is installed during the build.

In the mail list I showed two ways to extract the ruby version (http://trinity-devel.pearsoncomputing.net/?0::8083), but those are shell script methods. I don't know how to pass that information to the sources.

I would appreciate help with this. If I learn how to do this with amarok, I likely can do the same with tdebindings and koffice, although the latter has additional hurdles to overcome (obsolete ruby header files: http://bugs.pearsoncomputing.net/show_bug.cgi?id=735#c4).

Thanks much.

Created attachment 575 [details]
Fix amarok 3.5.13 compilation with Ruby 1.9 (and retains compatibilty with ruby 1.8)

Ok, here is a more polished patch that allow compilation with Ruby 1.9 but also with Ruby 1.8 .

Thanks much. I'll test with both ruby 1.8.x and 1.9.x.

For now, patches for ruby, libpng, and xine versions need to have these preprocessor tests. There is such a mixture of usage with the various distros. :-(

Created attachment 612 [details]
Updated patch

Francois,

I could not get the latest patch to work here against ruby 1.9.1. :-( The error was not finding ruby.h because the include path to ruby.h was incorrect.

The patch returned my ruby 1.9.1 include directory as:

/usr/lib/ruby/1.9.1/i486-linux

but here ruby.h is located in:

/usr/include/ruby-1.9.1/

I reworked the patch to combine my two-part patch with your patch. I now am able to build amarok against both ruby 1.9.1 and 1.8.7 with only one patch and no external build script support.

I verified the cmake variable HAVE_OLD_RUBY was correctly generated for each ruby version.

With the new patch, on my system, building against 1.8.7:

-- Found RUBY: /usr/bin/ruby
--   RUBY_INCLUDE_DIR: /usr/lib/ruby/1.8/i486-linux
--   RUBY_LDFLAGS: -Wl,-R -Wl,/usr/lib -L/usr/lib -lruby
--   RUBY_VERSION_MAJOR: 1
--   RUBY_VERSION_MINOR: 8
--   You have an old version of Ruby. (<1.9)

Building against 1.9.1:

-- Found RUBY: /usr/bin/ruby
--   RUBY_INCLUDE_DIR: /usr/include/ruby-1.9.1
--   RUBY_LDFLAGS: -Wl,-R -Wl,/usr/lib -L/usr/lib -lruby
--   RUBY_VERSION_MAJOR: 1
--   RUBY_VERSION_MINOR: 9

I did not use the cmake VERSION_LESS operator because I could not find anything on the web that the operator parses decimals into smaller pieces. Therefore I stayed my original method of stripping the decimal and comparing against "18" and "19." That still works. Please feel welcome if you want to add improved parsing to determine major and minor versions.

Would you please test the new patch against your system?

The only caveat to all of this is although amarok now builds against both versions of ruby, I have no way to actually test the final binary. I don't have any DAAP media device to do that. :-(

Created attachment 613 [details]
Updated updated patch for amarok 3.5.13 + ruby 1.8/1.9

Hello, your patch works for me EXCEPT that Fedora 17 now has 2 separate include directories for ruby include files ... So I added one more ruby variable "RUBY_ARCH" in the patch, so that it can work on Fedora 17.

Okay. Thanks.

I retested the latest patch against both 1.8.7 and 1.9.1. No build errors encountered with either.

As I mentioned, I have no way to actually test the usability of these changes. :-(

If you are content with what we have then I'll push to GIT. :-)

Yes, the latest patch now works for all the distributions I build TDE for.
I think you can now push it to GIT.

Patch pushed in GIT hash 8f79beaa. Resolved.

Thank you!