Picking apart Rubygems and Rake
I'm prepping for the 2.0.1 release of rubygame, which includes a number of bug fixes and improvements under the hood, especially in the way method arguments are processed in C methods. All the code is ready and waiting to be packaged up, but I'm tinkering with the Rakefile to make it play well with Rubygems, especially on win32 platforms.
In the 2.0.0 release, there were some snags supporting win32 users. The precompiled binaries were packaged up in gems so users wouldn't have to compile rubygame for themselves (this is more of an issue on win32 than on linux, which has the GNU C compiler available as a general rule). Unfortunately, the gem didn't work correctly for all users: despite the precompiled binaries being present, the Rakefile didn't think they had been compiled, and would throw a fit when it was unable to compile them for itself.
The problem seems to be that some ruby installations on win32 expect dynamic libraries to have the
.so extension (in *nix fashion), while others expect
.dll (in win32 fashion). The libraries in the rubygame gem end with
.so, but the Rakefile takes its hints from the ruby installation's config: on some systems, it would be looking for
My first thought, then, was to have the Rakefile rename the libraries at install-time to conform to the system's expectations. Even though they have the
.so extension, the libraries are win32-style DLLs inside, so I don't expect ruby to get confused when it tries to load them (it seems to ignore the extension anyway).
But here's the catch: when using rubygems, the
install task isn't run. I had read online somewhere that rubygems expects the Rakefile for compiled ruby extension to respond to two tasks:
extension (for compiling) and
install (for installing to the appropriate directory). It turns out, though, that it presently only uses the
extension task. (This I discovered only after rummaging through the source code for rubygems last night.)
Fortunately, this is not a big problem, because I can prepend a
fix_filenames task as a dependency of the
extension task, right before the
build task (which compiles the libraries if doesn't see that they have already been compiled):
This takes each of the prerequisites to the
install_ext task (each prereq is a String pathname to a compiled library file), checks whether the file exists with a
.so extension, and if so, renames it to the system extension for dynamic libraries (
DLEXT is derived from
Let's see if that does the trick.
UPDATE: One more tweak is needed to the
fix_filenames task, because the
mv command will complain if the source and destination are the same, which causes the task to fail on systems which actually do use
.so, like Linux. Here's a corrected version: