<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Redland librdf Language Bindings - Building and Installing from Source</title>
</head>
<body>
<h1>Redland librdf Language Bindings - Building and Installing from Source</h1>
<h2>1. Get pre-requisites</h2>
<p>The Redland Bindings require a previously built and installed
Redland package with the same version number. In particular, the
header files, shared libraries and SWIG interface files that Redland
provides are required for most language bindings. An alternative to
installation is to extract the Redland sources in a parent directory
or a sibling directory called 'librdf'.</p>
<h2>2. Getting the sources</h2>
<p>There are several ways to get the sources. The most stable and
tested versions are the sources shipped with each release and these
are recommended as the first place to start. For the latest
developent sources, anonymous GIT access is available but this may
require some configuring of developer tools that are not needed for
releases.</p>
<p>The source bundle and package files contain all the HTML files and
documentation provided on the web site.</p>
<h3>2.1. Getting the sources from releases</h3>
<p>The released sources and available from
<a href="http://download.librdf.org/source/">http://download.librdf.org/source/</a> master site as well as the
<a href="http://sourceforge.net/projects/librdf/">SourceForge site</a>.
</p>
<h3>2.2. Getting the sources from GIT</h3>
<pre>
git clone git://github.com/dajobe/redland-bindings.git
cd redland-bindings
</pre>
<p>At this stage, or after a <code>git pull</code> you will
need to create the automake and autoconf derived files, as described
below in <a href="#sec-create-configure">Create the configure program</a>
by using the <code>autogen.sh</code> script.</p>
<p>Building the Redland bindings in this way requires some particular
development tools not needed when building from snapshot releases -
automake, autoconf and swig.
The <code>autogen.sh</code> script looks for the newest versions
of the auto* tools and checks that they meet the minimum versions.</p>
<h2>3. Configuring and building</h2>
<p>Redland uses the GNU automake and autoconf to handle system
dependency checking. It is developed and built on x86 Linux
and x86 OSX but is also tested on other systems occasionally.
</p>
<p><code>configure</code> tries very hard
to find several programs and libraries that the Redland bindings
need. These include the binding binaries: perl, python, etc.,
C header files for the bindings such as for Python etc. and various
others. A summary of the parts found is given at the end of the
configure run. Several options to configure given below can be used
to point to locations or names of dependencies that cannot be
automatically determined.</p>
<h3><a id="sec-create-configure" name="sec-create-configure"></a>3.1. Create <code>configure</code> program</h3>
<p>If there is no <code>configure</code> program, you can create it
by running the <code>autogen.sh</code> script, as long as you have the
<a href="http://www.gnu.org/software/automake/automake.html">automake</a> and
<a href="http://www.gnu.org/software/autoconf/autoconf.html">autoconf</a>
tools. This is done by:</p>
<pre>
./autogen.sh
</pre>
<p>and you can also pass along arguments intended for configure (see
below for what these are):</p>
<pre>
./autogen.sh --prefix=/usr/local/somewhere
</pre>
<blockquote>
<p>On OSX you may have to explicitly set the <code>LIBTOOLIZE</code>
variable for the <code>libtoolize</code> utility since on
OSX <code>libtoolize</code> is a different program. The full
path to the utility should be given:</p>
<pre>
LIBTOOLIZE=/opt/local/bin/glibtoolize ./autogen.sh
</pre>
</blockquote>
<p>Alternatively you can run the automake and autoconf programs by
hand with:</p>
<pre>
aclocal; autoheader; automake --add-missing; autoconf
</pre>
<p>The automake and autoconf tools have many different versions and
<code>autogen.sh</code> enforces the minimums. At present development
is being done with automake 1.10.2 (minimum version 1.7), autoconf
2.63 (minimum version 2.54) and libtool 2.2.6 (minimum version 2.2.0).
These are only needed when compiling from GIT sources.
autogen.sh enforces the requirements.</p>
<h3>3.2. Options for <code>configure</code></h3>
<p>See also the generic GNU installation instructions in
<a href="INSTALL">INSTALL</a> for information about general options
such as <code>--prefix</code> etc.</p>
<dl>
<dt><code>--with-lua</code>(=<em>LUA-COMMAND</em>)<br /></dt>
<dt><code>--with-perl</code>(=<em>PERL-COMMAND</em>)<br /></dt>
<dt><code>--with-php</code>(=<em>PHP-COMMAND</em>)<br /></dt>
<dt><code>--with-python</code>(=<em>PYTHON-COMMAND</em>)<br /></dt>
<dt><code>--with-ruby</code>(=<em>RUBY-COMMAND</em>)<br /></dt>
<dd><p>Enable the given language APIs - the default is to build
no language APIs automatically. If the option value is omitted or
<em>yes</em>, configure will guess the location of the language
command. If the option value is <em>no</em> or no option is given,
the language API will be disabled - this is the default, not
to build any language API.</p>
<p>If the option is given a value, that is used as the appropriate
language command to use. For example <code>--with-ruby=ruby1.8</code>
will use the 'ruby1.8' binary, whereas <code>--with-ruby</code> will use
'ruby' as the binary, both of these will be searched for in the PATH.
An absolute path could alternatively be given such as
<code>--with-python=/opt/mypython/bin/python</code>
to use a python installation in a different location.</p></dd>
<dt><code>--with-perl-makemaker-args</code>=<em>ARGS</em><br /></dt>
<dd><p>Set the arguments for the Perl
<a href="http://perldoc.perl.org/ExtUtils/MakeMaker.html">ExtUtils::MakeMaker</a>
Makefile.PL invocation. The default arguments is ''. This is useful
to set the set of installation directories such as with
<code>--with-perl-makemaker-args=INSTALLDIRS=vendor</code>
to move the installation to the vendor directories. Useful choices
are '', 'perl', 'site' and 'vendor'. See the ExtUtils::MakeMaker
docs above for more information on the options.
</p></dd>
<dt><code>--with-python-get-python-lib-args</code>=<em>ARGS</em><br /></dt>
<dd><p>Set the arguments for the Python
<code>distutils.sysconfig</code> function
<a href="http://docs.python.org/distutils/apiref.html#module-distutils.sysconfig"><code>get_python_lib()</code></a> which determines the install directory
for the shared object for the python binding. The default value is ''
which puts the installed objects in the general library dir for
third-party extensions. Other useful values are probably '1' which
returns the platform-dependent library dir and '1,1' which returns
the standard library directory for platform-dependent libraries.
</p></dd>
<dt><code>--with-python-ldflags</code>(=<em>FLAGS</em>)<br /></dt>
<dd><p>Set the linker flags for linking Python. This can also be
done by setting the environment variable <code>PYTHON_LDFLAGS</code>.
If neither is set, <code>configure</code> will guess an appropriate
set for the current system. Cygwin example:</p>
<pre>
-with-python-ldflags='-shared -L/usr/lib/python2.5/config -lpython2.5'
</pre>
</dd>
<dt><code>--with-python-libext</code>=<em>.EXT</em><br /></dt>
<dd><p>Set the python shared library link extension (default <code>.so</code>).
Useful on systems where .so does not work as a shared library extension.
Cygwin example:</p>
<pre>
-with-python-libext=.dll
</pre>
</dd>
<dt><code>--with-ruby-install-dir</code>=<em>DIR</em><br /></dt>
<dd><p>
Set the directory to install the archhitecture-independent Ruby bindings files.
The default value is '' which will install the files to directory given
by the the value of the <code>Config::CONFIG['rubylibdir']</code> variable
</p></dd>
<dt><code>--with-ruby-arch-install-dir</code>=<em>DIR</em><br /></dt>
<dd><p>
Set the directory to install the architecture-specific Ruby bindings files.
The default value is '' which will use the value of the variable
configured by <code>--with-ruby-arch-install-dir-variable</code> to get
the the installation directory.
Setting this configuration overrides setting the variable name.
</p></dd>
<dt><code>--with-ruby-arch-install-dir-variable</code>=<em>NAME</em><br /></dt>
<dd><p>
Set the <code>Config::CONFIG['sitearchdir']</code> variable name
to get the the installation directory for installing architecture-specific Ruby
bindings files. The default variable is 'archdir'.
Other useful values are probably 'sitearchdir'.
This is overridden if <code>--with-ruby-arch-install-dir</code> is set.
</p></dd>
</dl>
<h3>3.3 Configuring</h3>
<p>If everything is in the default place, do:</p>
<pre>
./configure
</pre>
<p>More commonly you will be doing something like this, indicating
which binding or bindings are wanted:</p>
<pre>
./configure --with-python
</pre>
<p>NOTE: It is usually safe to use older redland bindings with newer
redland releases, it will just omit any new functions added.
<code>configure</code> may warn about this and stop, and if this is
the case, you can override it with <code>--with-redland=system</code>
to let configuration continue.
</p>
<p>If you are having problems with configuring several times when
adding or removing options, you may have to tidy up first with either
of these:</p>
<pre>
make clean
rm -f config.cache
</pre>
<h3>3.4 Compiling</h3>
<pre>
make
</pre>
<h2 id="sec-testing">3.5. Testing</h2>
<p>You can build and run the built-in tests for Redland with:</p>
<pre>
make check
</pre>
<p>which will run these tests for the enabled languages. These
<em>may fail</em> if the main redland libraries (librdf and
raptor, rasqal) are not installed but are used in nearby source trees.
So in this case you should install redland, raptor and rasqal first</p>
<p>The language-specific tests can also be built and run with:</p>
<pre>
cd language
make check
</pre>
<h3 id="sec-install">3.6 Installing the bindings</h3>
<p>To install the bindings, do:</p>
<pre>
make install
</pre>
<p>Otherwise, the language-specific installations can be made with:</p>
<pre>
cd language
make install
</pre>
<h2>4. Using the library</h2>
<p>There are many examples for all of the language interfaces in the
corresponding sub-directories such as <code>perl/example.pl</code>
which may be easier to modify.</p>
<h2>5. Using the Perl interface</h2>
<p>See the <a href="docs/perl.html">Redland Perl Interface</a> document for
full information on installing and using Redland from Perl.</p>
<h2>6. Using the Python interface</h2>
<p>See the <a href="docs/python.html">Redland Python Interface</a> document for
full information on installing and using Redland from Python.</p>
<h2>7. Using the Ruby interface</h2>
<p>See the <a href="docs/ruby.html">Redland Ruby Interface</a> document for
full information on installing and using Redland from Ruby.</p>
<h2>8. Using the PHP interface</h2>
<p>See the <a href="docs/php.html">Redland PHP Interface</a> document for
full information on installing and using Redland from PHP.</p>
<hr />
<p>Copyright (C) 2004-2011 <a href="http://www.dajobe.org/">Dave Beckett</a><br />Copyright (C) 2004-2005 <a href="http://www.bristol.ac.uk/">University of Bristol</a></p>
</body>
</html>