[Kde-bindings] korundum, its build system and ruby 1.9

[Stefano Crocco]

I'm in the process of writing a gentoo ebuild of korundum (for those who don't 
know gentoo, an ebuild is a gentoo package: a file containing the instructions 
to compile a program so that it can be installed). I have already attempted 
this a few months ago but I had to give up for lack of time (by the way, I 
feel the need to apologize: at the time, the members of this list helped me 
much by answering my questions, but I never explained what happened of my 
attempt). Now, with more time availlable, I have succeded in writing two 
almost working ebuilds: one for korundum with ruby 1.8 and one for korundum 
with ruby 1.9. They're "almost working" in the sense that they can't be 
installed at the same time, for reasons I'll explain below. 

While writing the ebuild, I found some issues with the korundum and its build 
system when it comes to building for ruby 1.9, so I thought to write this mail 
to discuss them.

1) (maybe this issue should be reported as a bug for kdelibs but, since I'm
already wrining this message, and it's not out of topic, I decided to
include it. Feel free to tell me if it isn't the correct place)
the FindRUBY cmake module included in kdelibs doesn't work well with ruby 
1.9 if the latter has been installed using a suffix (that is, if the 
executable is called, for example, ruby19 or ruby1.9). The problem is that 
FindRUBY always looks for the ruby.h include file in either ${RUBY_ARCH_DIR}, 
which is where the file is in ruby 1.8 or in 
/usr/include/ruby-${RUBY_VERSION}, where RUBY_VERSION can be, for example 
1.9.1. If ruby was built for a suffix, let's say 19, then its include files 
will be put in /usr/include/ruby19-1.9.1, so ruby.h won't be found. All this 
means that if the user has ruby built with a suffix (which I think is what 
most users have), he has to pass all the ruby related paths to cmake, which 
isn't very user-friendly. A solution can be to replace the 
/usr/include/ruby-${RUBY_VERSION} path with 
/usr/include/${RUBY_INSTALL_NAME}-${RUBY_VERSION}, where RUBY_INSTALL_NAME is 
obtained from ruby itself just like RUBY_LIB_PATH or RUBY_VERSION (in ruby 
1.9, RbConfig::CONFIG has an entry called "ruby_install_name" which returns 
the name of the ruby executable).

While writing the above, I started wondering why to use cmake to search for 
such paths when ruby already knows where they are. For instance, we can find 
the ruby include directory from within ruby with 
RbConfig::CONFIG['rubyhdrdir'] 
in ruby 1.9 and with 
File.join(RbConfig::CONFIG['rubylibdir'],RbConfig::CONFIG['arch'])
in ruby 1.8
and the library path with 
File.join(RbConfig::CONFIG['rubylibdir'],RbConfig::CONFIG['LIBRUBY'])
I'm not a cmake expert, however, so there may be reasons for not doing so 
which I'm not aware of.

2) compilation of qtruby with ruby 1.9 fails because the config.h file can't 
be found. I read somewhere on this mailing list that, to make it work, you 
should add a symbolic link in the ruby include directory to the config.h file, 
which is located in an arch-dependent subdirectory. There are two problems 
here: the first is that this isn't mentioned anywhere in the documentation (at 
least, I couldn't find it); the second is that this doesn't work well with 
distributions like gentoo where a package is configured and built in a sandbox 
and can't modify the live file system before being fully built. The reason for 
which the link is needed is that ruby.h includes ruby/ruby.h which, in turn, 
includes "ruby/config.h". Since the only ruby-related include path passed to 
the compiler is the ruby include directory, for example, 
/usr/include/ruby-1.9.1, the config.h file will only be searched in 
/usr/include/ruby-1.9.1/ruby/, while it instead is in 
/usr/include/ruby-1.9.1/${ARCH}/ruby/, were ARCH is depends on the system and 
can be found from ruby using RbConfig::CONFIG['arch']. So, a much better 
solution to this problem is to add this directory to the include path when 
building for ruby 1.9

3) it's not easy to have a working installation of qtruby for both ruby 1.8 
and ruby 1.9 at the same time. While most of the libraries 
linked with libruby are installed in the site_ruby subdirectory of the 
respective versions of ruby, three of them are installed in the same directory 
regardless of the ruby version. They are: libqt4shared.so, which is installed 
in ${CMAKE_INSTALL_PREFIX} and krubypluginfactory.so and krossruby.so, which 
are installed in the lib subdirectory of the KDE installation directory. Of 
course, this means that to have korundum installed for both versions of ruby, 
you have to use two different CMAKE_INSTALL_PREFIX, and adjust the LDPATH 
environment variable depending on which version you want to use. I don't know 
why and/or whether such libraries can't be installed in the site_ruby 
directory of the appropriate ruby installation directory, but assuming they 
can't, couldn't be they given a different name depending on the ruby version? 
for example libqt4shared18.so for the ruby 1.8 version and libqt4shared19.so 
for the 1.9 one? Of course, the cmake entries for all the libraries should be 
corrected accordingly. I tried this on my ebuilds and it seems to work.

4) unlike the previous three points, this may be more an issue related to what 
I'm doing (writing a gentoo ebuild) than a general issue. My problem is that 
there are a number of files which are the same for both versions of ruby (in 
particular, the various files for the plasma widgets and the include files). 
This makes it problematic to write two different ebuilds, one for ruby 1.8 and 
one for ruby 1.9, since such files would belong to both, which shouldn't 
happen. Also, in gentoo you usually install both the ruby 1.8 and the ruby 1.9 
version of a package with the same ebuild, so I'd like to provide the same. I 
don't yet know how to do that (I guess I'll have to do heavy modifications to 
the CMakeLists.txt files), but I'm wondering whether it wouldn't be a good 
idea if korundum provided such a possibility itself, so that the user who 
wants both version installed can do so with a single run of cmake/make/make 
install.

5) korundum doesn't compile with ruby 1.9 if nepomuk is enabled. The error I 
get is the following:

/var/tmp/paludis/kde-base-kdebindings-ruby19-9999/work/kdebindings-ruby19-9999/ruby/nepomuk/nepomukhandlers.cpp: In function 'void marshall_QHashQUrlNepomukVariant(Marshall*)':
/var/tmp/paludis/kde-base-kdebindings-ruby19-9999/work/kdebindings-ruby19-9999/ruby/nepomuk/nepomukhandlers.cpp:49: error: 'struct RArray' has no member named 'len'
make[2]: *** [ruby/nepomuk/CMakeFiles/rubynepomuk.dir/nepomukhandlers.o] Error 1
make[1]: *** [ruby/nepomuk/CMakeFiles/rubynepomuk.dir/all] Error 2

For the second and third point, I have already found out what needs to be 
changed in the build system to make the changes I described. If the developers 
think it's a good idea, I can post them (they'll need a little polishing, 
otherwise I'd have attached them to this email). I'm still working on the 
first point. Regarding the fourth point, I've not started working on it as yet 
(both because I wanted to have everything else working before doing that and 
because it seems more difficult than the rest). If it is a feature worth 
adding to the korundum build system, I'll try to change the CMakeLists.txt in 
a way which is suitable for a generic system, otherwise I'll do so in a 
gentoo-specific way.

Any comment will be appreciated

Thanks

Stefano