Q: How to compile Ruby API into multiple client libraries My team is currently creating an API that will interact with our core Ruby API.
The new API is for the public as the Ruby API is our private API.  We want to be able to compile this new API into a PHP, Java, Python, etc., client libraries when we are ready to release. 
Are there any gems, or other ways to write this new API so we can compile it into different client libraries? 

A: There are several ways to think about exposing an API these days.  If we're talking about creating a library in the sense of something compiled into other applications, that takes us down one path.  If we're talking about providing, effectively, command line functionality callable from other contexts as system calls, that's another story.  More broadly is the API is more of a service, like REST, that's different.  I'll assume one of the first two.
There are several tools that will create a binary package for platforms.  Look at ruby-tioolbox.com for some examples.  None of these are compiling true executable code (as far as I know) but mainly provide an executable version of ruby with your code and dependencies packaged up.  Perhaps the API appears callable as a system library (DLL for Windows, SO for UNIXy).
But either way, I would think you're dealing with ruby and your code loading and running as a separate process on each call.  There's a library like this (not in Ruby) called ImageMagick, with a wrapper for ruby calls called MiniMagick that might be a pointer to the kind of pattern you're looking for.
If you want to run ruby and your app as a service, there are several tools for this -- this helps address the overhead of loading a process each time, and built into Ruby 1.9 is a Process class that daemonizes ruby, although presumably only on Unix.  Check this SO answer
The best answer is probably that ruby, like other similar languages (e.g. Python) are really not designed to be low-level system libraries.  There are likely many ways of accomplishing what you want in a given environment (notably Linux) ... but as far as I know nothing that really exposes executable codepoints to all languages.
