-
Notifications
You must be signed in to change notification settings - Fork 25
/
INSTALL.html
336 lines (261 loc) · 12.2 KB
/
INSTALL.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
<?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>
<dt><code>--with-ruby-linking</code>=<em>TYPE</em><br /></dt>
<dd><p>
Set the Ruby module linking type: one of 'so', 'dylib' (OSX) or
'bundle' (OSX). Otherwise the defaults are guessed.
</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>
<p><b>NOTE</b>: For some language bindings you may need to set the
shared library search path before the tests will work, if Redland's
<code>librdf.so</code> (librdf.dylib etc.) is not installed in a
standard system library patth such as /usr/lib (if it was installed
with <code>--prefix=/usr</code>.
On most systems you can set the <code>LD_LIBRARY_PATH</code>
environment variable to include the directory where the
<code>librdf</code shared library is found. (On OSX this is
<code>DYLD_LIBRARY_PATH</code>). You can also configure it via a
system wide file - see the <code>ld</code>, <code>ld.so</code>,
or<code>ld.so.1</code> or <code>dyld</code> manual pages for details.
</p>
<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-2013 <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>