You're not currently signed in.

This describes the way I (BrettNeumeier) installed SVK, including all of the stuff it depends on, on my Linux box. My goal was to have the latest released versions of everything; I was successful except with Neon, since Subversion won't work with the latest Neon version. Oh, and also I didn't build the standalone APR 1.2.1, I just used the APR that comes with Apache HTTPD.

There are also some notes embedded in some of the sections below about building this on MacOS X, which is a little bit tricky.

ENVIRONMENT SETUP

Everything is going to be built into /usr/local/vc. If you don't

like that, do something else instead! (Just change the value of

VC in the first line of code.)

Make sure the $VC directory exists, wherever it is, and the

current user can write to it. I don't like to build any of this

stuff as root; if I wanted to do that, I'd build it to /usr/local

or some other normal location.

For Mac OS X, it seems like LD_LIBRARY_PATH might be called

DYLD_LIBRARY_PATH. When building for OS X, I specified both.

--------------------- code ---------------------

export VC=/usr/local/vc

export SSL=/usr/local/ssl



cat > $VC/setenv <<HERE

export VC=${VC}

export SSL=${SSL}

export PATH=\${SSL}/bin:\${VC}/bin:\$PATH

export LD_LIBRARY_PATH=\${SSL}/lib:\${VC}/lib:\$LD_LIBRARY_PATH

export CFLAGS="-O3 -fPIC -fomit-frame-pointer"

export CFLAGS="\$CFLAGS -I\${VC}/include -I\${SSL}/include"

export LDFLAGS="-L\${VC}/lib -L\${SSL}/lib"

HERE



chmod a+x $VC/setenv

. $VC/setenv

--------------------- code ---------------------


EXPAT (1.95.8) ( http://expat.sourceforge.net )

--------------------- code ---------------------

./configure \

  --prefix=$VC \

  --with-gnu-ld \

  --with-pic

make

make install

--------------------- code ---------------------


PERL (5.8.7) ( http://www.perl.org )

--------------------- code ---------------------

./configure.gnu --prefix=$VC

make

make install

--------------------- code ---------------------


OPENSSL (0.9.8) ( http://www.openssl.org/ )

This bit actually gets installed to /usr/local/ssl, because you

always ought to have OpenSSL there. It's very handy to have

around. That does mean you have to be privileged enough to write

to /usr/local/ssl.

--------------------- code ---------------------

./config

time make

time make test

time make install

--------------------- code ---------------------


APACHE HTTPD (2.0.54) ( http://httpd.apache.org/ )

It turns out with Subversion 1.1.4, and presumably later, you

don't need to build Apache (or, later, Neon) -- it includes the

parts of those packages that it needs. I personally prefer to

build the standalone pieces separately, but I don't really have a

good reason for that preference. If you want to build these

pieces separately like I'm doing here, then you can get rid of

the apr, apr-util, and neon subdirectories of the subversion

source tree after unpacking it.

With OpenSSL 0.9.8, there's a slight incompatibility: the

constant PEM_F_DEF_CALLBACK has changed to

PEM_F_PEM_DEF_CALLBACK, so references to it need to be changed in

the Apache HTTPD source code. That means:

--------------------- code ---------------------

for file in modules/ssl/{ssl_toolkit_compat.h,ssl_engine_pphrase.c}

do

    sed -i "s@PEM_F_DEF_CALLBACK@PEM_F_PEM_DEF_CALLBACK@g" $file

done

--------------------- code ---------------------



It's a little irritating, but I think worth it to be using the

latest version of everything.

You do not technically need to enable all of these things. I

went a little crazy with it.

On Mac OS X, DSO support doesn't work properly (as noted below in the Subversion section). It might be a good idea to adjust the HTTPD build accordingly.

--------------------- code ---------------------

./configure \

  --prefix=$VC \

  --enable-dav \

  --enable-so \

  --enable-mods-shared=all \

  --enable-auth-anon \

  --enable-auth-dbm \

  --enable-auth-digest \

  --enable-file-cache \

  --enable-echo \

  --enable-charset-lite \

  --enable-cache \

  --enable-disk-cache \

  --enable-mem-cache \

  --enable-example \

  --enable-case-filter \

  --enable-case-filter-in \

  --enable-ext-filter \

  --enable-include \

  --enable-deflate \

  --enable-log-config \

  --enable-log-forensic \

  --enable-logio \

  --enable-env \

  --enable-mime-magic \

  --enable-cern-meta \

  --enable-expires \

  --enable-headers \

  --enable-usertrack \

  --enable-unique-id \

  --enable-setenvif \

  --enable-proxy \

  --enable-proxy-connect \

  --enable-proxy-ftp \

  --enable-proxy-http \

  --enable-ssl \

  --enable-optional-hook-export \

  --enable-optional-hook-import \

  --enable-optional-fn-import \

  --enable-optional-fn-export \

  --enable-bucketeer \

  --enable-http \

  --enable-dav \

  --enable-info \

  --enable-suexec \

  --enable-cgi \

  --enable-cgid \

  --enable-dav-fs \

  --enable-vhost-alias \

  --enable-speling \

  --enable-rewrite \

  --with-ssl=$SSL

make

make install

--------------------- code ---------------------


NEON (0.24.7) ( http://www.webdav.org/neon/ )

Neon, like Apache's APR, is bundled with subversion, so just like

with Apache you can omit this section if you want to use the Neon

that's included. Neon 0.25.2 is the latest as of this writing,

but is not backward-compatible; Subversion 1.2.x and earlier

don't support it.

The configure script that comes with Neon doesn't detect OpenSSL

0.9.8 properly; I can't figure out the problem, but it can't

figure out that the function SSL_library_init is in libssl. The

funny environment variable just tells it what it should figure

out on its own.

--------------------- code ---------------------

ne_cv_libsfor_SSL_library_init="-lssl" ./configure \

  --prefix=$VC \

  --enable-shared=yes \

  --enable-static=yes \

  --with-gnu-ld \

  --with-pic \

  --with-zlib \

  --with-ssl \

  --with-libs=/usr/local/ssl

make

make install

--------------------- code ---------------------


PYTHON (2.4.1) ( http://www.python.org )

--------------------- code ---------------------

./configure \

  --prefix=$VC \

  --enable-shared

make

make install

--------------------- code ---------------------


SWIG (1.3.25) ( http://www.swig.org )

Subversion 1.1.4 and later finally allow current versions of SWIG

to be used.

--------------------- code ---------------------

./configure \

  --prefix=$VC \

  --with-python=${VC}/bin/python \

  --with-perl5=${VC}/bin/perl

make

make install

--------------------- code ---------------------


SUBVERSION (1.2.3) ( http://subversion.tigris.org/ )

If you've built the standalone apr and apr-util (as part of

Apache) and neon earlier, delete those subdirectories from the

subversion bundle after unpacking the tarball.

For Mac OS X, do not specify --enable-dso. DSO support does not work properly; if you try to use DSO, you'll wind up with a Subversion that can't find the fsfs library.

--------------------- code ---------------------

./configure \

  --prefix=${VC} \

  --enable-swig-bindings=perl,python \

  --enable-dso \

  --with-apr=${VC} \

  --with-apr-util=${VC} \

  --with-gnu-ld \

  --with-pic \

  --with-neon=${VC} \

  --with-apxs=${VC}/bin/apxs \

  --with-zlib \

  --with-swig=${VC} \

  --disable-neon-version-check

--------------------- code ---------------------



This may produce some ugly warnings about how Berkeley DB isn't

around. This is fine, since we're using FSFS as the subversion

filesystem backend.

--------------------- code ---------------------

make

make install

make swig-py

make install-swig-py

make swig-pl

make check-swig-pl

make install-swig-pl

--------------------- code ---------------------



To get the python bindings to work properly, the python modules

need to be in the correct directory (site-packages).

--------------------- code ---------------------

ln -s ../../svn-python/libsvn $VC/lib/python*/site-packages

ln -s ../../svn-python/svn $VC/lib/python*/site-packages

--------------------- code ---------------------



You don't really need the Python modules for SVK. The reason that Python is here at all is that I'm also using this build of Subversion with Trac ( http://projects.edgewall.com/trac ). Also I have a vague recollection that in a previous version of these instructions I needed Python and the Python SWIG bindings in order to run the Subversion tests.

PERL MODULES

There are, as I mentioned before, a huge number of perl modules

that are needed in order to get SVK to work. Since each one is

installed the same way, there's no point in having separate

sections for each one.

To build these pieces, just make sure that all of the appropriate

perl module files are unpacked into (subdirectories of) the

current working directory, and go through each of the modules in

the order specified below doing "perl Makefile.PL; make; make

test; make install".

Perl modules can be obtained from CPAN. There may be a more

effective method than just searching for each module in turn, but

if so I don't know it. (There is probably a "perl -m CPAN"

option that does that, as a matter of fact.)

Note that in a few cases, the "perl Makefile.PL" command will

want some input from the terminal. Just use all the defaults,

EXCEPT that the first time SVK is being installed, it will ask

whether it should install SVN::Mirror from CPAN, with a default

of yes. Say no to that one. In fact, say "no" any time a module

wants to install anything from CPAN; that defeats the purpose of

building everything manually from source. (If there are missing

dependencies, just adjust the modules-in-order list below to fix

the problems.)

SVK has an optional dependency on SVN::Mirror; SVN::Mirror

requires SVK. So SVK is installed twice, once before SVN::Mirror

and once after. Also, some SVN::Mirror tests depend on

VCP::Dest::svk, which depends on SVK...this is kind of kludgy.

Each of the modules is built with:

perl Makefile.PL && make && make test && make install



Sometimes some of the tests may fail. If so, the install part

won't happen automatically. You'll have to decide based on the

test results whether you want to soldier on and install anyway.

It is oh-so-tempting to create a big bash (or other) script to

churn through all of these modules, building and installing them

all automatically. I have found that this is a good way to get

things to fail at some point; it might be a better idea to go

through the module list manually.

Build the modules in the following order ...

Algorithm-Diff-1.1901

Algorithm-Annotate-0.10

YAML-0.39

Regexp-Shellish-0.93

Clone-0.18

Data-Hierarchy-0.21

Pod-Escapes-1.04

Pod-Simple-3.02

PerlIO-via-dynamic-0.11

PerlIO-via-symlink-0.05

IO-Digest-0.10

SVN-Simple-0.27

DateManip-5.44

File-Type-0.22

URI-1.35

PerlIO-eol-0.13

Class-Autouse-1.20

TimeDate-1.16

Locale-Maketext-Lexicon-0.49

Locale-Maketext-Simple-0.12

IO-Pager-0.06

TermReadKey-2.30

File-chdir-0.06

Class-Accessor-0.22

HTML-Tagset-3.04

HTML-Parser-3.45

IPC-Run3-0.030

HTML-Tree-3.18

Font-AFM-1.19

HTML-Format-2.04

PodToHTML-0.05

Text-Diff-0.35

XML-AutoWriter-0.38

XML-Parser-2.34

VCP-autrijus-snapshot-0.9-20050110

Data-UUID-0.11

Sort-Versions-1.5

Compress-Zlib-1.40

FreezeThaw-0.43

Test-Builder-Tester-1.01

Test-Pod-1.20

SVK-1.04

VCP-Dest-svk-0.28

SVN-Mirror-0.67

SVK-1.04

SVN-Mirror-0.67



That's the last one. Yay, you're done.

-BrettNeumeier