Figure 17.2 on page 182 shows the overall workflow when building an
The key to the whole process is the
program which you, as a developer, create. In
write a simple program that determines what features are available on
the user's system and where those features may be located. Executing
builds a customized
, tailored for both your application and the system on
which it's being compiled. When you run the
, your extension is built and (optionally) installed.
may be just two lines long, and for many
extensions this is sufficient.
The first line brings in the
(documented beginning on page 451). This contains all the
commands we'll be using. The second line creates a
extension called ``Test.'' (Note that ``Test'' is the name of the
extension; the makefile will always be called ``Makefile.'')
will be built from all the C source files in the
Let's say that we run this
program in a directory
containing a single source file,
result is a
that will build our extension. On our system,
this contains the following commands.
gcc -fPIC -I/usr/local/lib/ruby/1.6/i686-linux -g -O2 \
-c main.c -o main.o
gcc -shared -o Test.so main.o -lc
The result of this compilation is
, which may be
dynamically linked into Ruby at runtime with ``
''. See how
commands have located platform-specific libraries and
used compiler-specific options automatically. Pretty neat, eh?
Although this basic program works for many simple extensions, you may
have to do some more work if your extension needs header files or
libraries that aren't included in the default compilation environment,
or if you conditionally compile code based on the presence of
libraries or functions.
A common requirement is to specify nonstandard directories where
include files and libraries may be found. This is a two-step process.
should contain one or more
This specifies a tag for a set of directories. Then, when you run the
program, you tell
where the corresponding
physical directories are on the current system.
contains the line
then you give the location of the corresponding directories with the
include to the compile command.
lib to the link command.
If (as is common) your include and library directories are both
subdirectories of some other directory, and (as is also common) they're
, you can take a shortcut:
lib and directory/
include to the link
command and compile command, respectively.
There's a twist here. As well as specifying all these
options when you run
, you can also use the
options that were specified when Ruby was built for your machine. This
means you can find out the locations of libraries that are used by
To make all this concrete, lets say you need to use libraries and
include files for the CD jukebox we're developing. Your
program might contain
# .. more stuff
You'd then run
with something like:
% ruby extconf.rb --with-cdjukebox-dir=/usr/local/cdjb
would assume that the libraries were in
and the include files were in
command adds to the list of places to search
for libraries and include files. It does not, however, link the
libraries into your application. To do that, you'll need to use one
a given entry point in a named library. If it finds the entry point,
it adds the library to the list of libraries to be used when linking
similar, but allows you to specify a list of directories to search for
On some platforms, a popular library may be in one of several places.
The X Window system, for example, is notorious for living in different
directories on different systems. The
search a list of supplied directories to find the right one (this is
, which uses only configuration
information for the search). For example, to create a
that uses X Windows and a jpeg library,
if have_library("jpeg","jpeg_mem_init") and
find_library("X11", "XOpenDisplay", "/usr/X11/lib",
puts "No X/JPEG support available"
We've added some additional functionality to this program. All of the
if they fail. This means that
we can write an
that generates a
everything it needs is present. The Ruby distribution does
this so that it will try to compile only those extensions that are supported
on your system.
You also may want your extension code to be able to configure the
features it uses depending on the target environment. For example, our
CD jukebox may be able to use a high-performance MP3 decoder if the
end user has one installed. We can check by looking for its header
We can also check to see if the target environment has a particular
function in any of the libraries we'll be using. For example, the
call would be useful but isn't always
available. We can check for it with:
preprocessor constants if they find their targets. The names are
formed by converting the target name to uppercase and prepending
``HAVE_''. Your C code can take advantage of this using constructs
# include <hp_mp3.h>
err = setpriority(PRIOR_PROCESS, 0, -10)
If you have special requirements that can't be met with all
commands, your program can directly add to the global
, which are passed to the
compiler and linker, respectively.