So, as I said, I wanted to try some alternative to automake for RubyTag++ as I was able to get rid of M4 for the bindings’ generation. CMake was my choice as KDE is using that for the work on the new KDE major version (KDE 4).
This was also an experiment as I wanted to know how it worked, as I’ll have probably to fight with that build system when KDE 4 will be released.
So I’ve emerged it, and for first thing, I looked if it had some kind of support for ruby, I found the /usr/share/cmake/Modules/FindRuby.cmake file and looked at it. I think I rarely seen something that broken. First of all, it doesn’t really look for all the needed information to make use of Ruby, like the path where to install the ruby extensions.
A part that, that might just be a simple omissis that’s not “the best”, it also hardcodes the include path to “i386-linux” that, mind you, it’s entirely broken on anything that’s not i386 and Linux, and if your CHOST is i686, that breaks, too.
It also looks for the library libruby1.8.so and the ruby1.8 executable, that are not common, on Gentoo for instance they are libruby18.so and ruby or ruby18.
So now I have at least to rewrite the Ruby check module, to be able to use CMake, possibly in a better way so that the important variables I need to build and install the extension. Then I have to submit it upstream, and then maybe it will be available next version. In the mean time, I don’t think I can release rubytag even if my generator is completed.
This said, I don’t think the first impressions with CMake are that good, for me.