Hurrah! Hurrah! Leopard is here! Sing Hosanna!
… well. Not quite. I’ve installed leopard and it’s quite nice, although some aspects are going to take some getting used to. In a nutshell, it feels like there’s a lot of eye candy, but I’m reassured that it’s an improved platform underneath all the transparency and animation.
But, I digress; Of course, we’ve all known for a while that Leopard was going to come with some nice Ruby libraries and frameworks baked in. FYI, Leopard comes with the following (amongst many other) Ruby libraries:
- RubyGems (and a bunch of gems)
- SQLite bindings
- RubyCocoa (look in /Developer/Examples/Ruby/RubyCocoa, or at this video if you’re feeling brave, for examples)
While bundling all this neat Rubinicity up for us is is great, many (me included) still like to maintain our own toolchain - sometimes it’s just nicer to be in full control of the dependencies and extra bells and whistles that we might like to install, and to know that we can match our development and deployment environments reasonably closely. However, that doesn’t mean that we are forever kept apart from whatever tweaks Apple has made to our beloved language; they have made their patches and build information available for the entire set of open-source software they’ve bundled with 10.5.
- making the MD5 and SHA1 libraries use CommonCrypto instead of OpenSSL
- compiling most libraries as 4-way fat (i386, ppc, x86_64 and ppc64)
- having ruby emit DTrace static probes when entering/leaving a Ruby method
As someone who’s played around with building various Ruby extensions on a Mac for some time, it’s going to be interesting looking at how they’ve changed the build process so that it best integrates with the other system libraries and frameworks. There’s also the XCode template project for a new Ruby Dynamic Library. You can even look at the apple-default IRB configuration here. Nice.
comments powered by Disqus