Building Subversion on MacOS X Tiger

I started to work in the Sparta Orlando office July 5th. As part of my new job I decided to install a SCM system that I, and others in the office, could use. After talking to the other developers we decided to install Subversion, and to make it available over the local webserver. What follows are my adventures over several days attempting to build, install, and integrate everything.

As I said I spent the latter part of last week finally gathering and installing all the pieces for a web-based subversion server on an Apple blade server running MacOS X Tiger, and then trying to get them all to play nice together. What follows are all the steps and settings required to get everything built and running. In order to duplicate my results, you need the following applications in tarball format.

• Berkeley db 4.3.28 (the Subversion repository will use Berkeley)
  
• Apache 2.0.54
• PHP 5.0.4
• Subversion 1.2.1
  

You also need to make sure that you have the latest tool chain installed on Tiger. The system I worked on had Panther (10.3) installed originally. When it was upgraded to Tiger (10.4) the CD-ROM disks, not the DVD-ROM, was used because the blade server only came with a CD-ROM. This meant that the Panther developer tool chain did not get upgraded. The problem when this happens is that the older libtool is unable to properly build libraries for Tiger. Before I could successfully build and install all the tarballs I had to uninstall the older developer tools, then download XCode 2.1 from the Apple developer site and install the new developer tools. This turned out to be a painless if long process. You uninstall the tools (as root) by executing /Developer/Tools/uninstall-devtools.pl. Then, after downloading xcode_tools_2.1.dmg with Safari, Tiger automatically mounts the disk image and allows you to run the tools inside the CD-ROM image necessary to install XCode 2.1 developer tools from that image. Slick.

With the latest tools in place, I was ready to build all the tarballs. The instructions for building all the subsystems seem to be scattered across notes in the tarballs as well as the web, and from what I've read and tried to follow, they're incomplete in various ways. What I'm about to show you will build, and when finished will execute.

The server is a production server, so I tried to perform everything in a sandbox as much as possible. I untarred all the tarballs under my login directory, and with the exception of Berkeley db I installed everything under /opt. The first package to be unpacked and built was Berkeley db 4.3.28. I configured Berkeley to build stock with no configuration switches. I changed directory into build_unix and simply ran ../dist/configure. When it finished building I ran 'make install' as root and it was placed under /usr/local/BerkeleyDB.4.3. This default did not clobber anything already under /usr/local and it made it easier to build the rest of the applications.

Apache 2 was built next. The following configuration switches were used to build a module-based Apache 2 installation that supports Subversion.

#! /bin/sh
#
# Created by configure

"./configure"
"--prefix=/opt/httpd"
"--enable-dav=shared"
"--enable-so"
"--with-dbm=db43"
"--with-berkely-db=/usr/local/BerkeleyDB.4.3"
"--enable-ssl=shared"
"$@"

I cannot begin to tell you how important it is to include '=shared' on every '--enable-feature' switch. I had to go and read the Apache documentation before the clue light came on. I would build Apache and install it with the features enabled, only to look in the modules subdirectory and not find mod_dav.so, needed by Subversion. Simply adding '--enable-dav' will build DAV support, but will link it into the Apache binary, not create the independent shared object (so) module. The whole idea behind Apache modules is the ability to add new features without having to rebuild the http server and not link them in. Or at least that's the theory. When it was installed I modified httpd.conf to listen on port 8080.

I built PHP 5.0.4 next because it's also a module and because we already use the MacOS X Tiger Apache server for other uses and it also has PHP. Unfortunately MacOS X Tiger uses Apache 1.3.33. We now have a plan in place to eventually migrate from the built-in 1.3.33 to 2.054. In order to do that PHP has to be installed and enabled. The configuration switches for building PHP are:

#! /bin/sh
#
# Created by configure

'./configure'
'--prefix=/opt/php5'
'--with-apxs2=/opt/httpd/bin/apxs'
'--with-mysql=/usr/local/mysql'
'--with-config-file-path=/opt/php5'
"$@"

After installing PHP the following changes were made to Apache's httpd.conf file.

DirectoryIndex index.html index.php index.html.var
...
LoadModule php5_module        modules/libphp5.so
...
AddType application/x-httpd-php .php

And to test the installation, the following tiny PHP file (test.php) was added to the htdocs directory.

<html>
<head>
<title>PHP 5 Information</title>
<body>
<?php phpinfo(); ?>
</body>
</html>

When you run this simple page under Apache and call phpinfo(), you get all sorts of interesting PHP information.

Finally, I configured and built subversion. The following are the switches for building subversion in this environment.

#! /bin/sh
#
# Created by configure

"./configure"
"--prefix=/opt/subversion"
"--with-apxs=/opt/httpd/bin/apxs"
"--enable-shared"
"--with-ssl"
"$@"

Once installed, Apache's httpd.conf file has to be modified as show below. Note that I'm listing all the modules currently referenced in the order that appears to work. Also note that while the Subversion install will add the dav_svn_module and authz_svn_module to the httpd.conf file, you have to go in by hand and add the dav_module.

LoadModule dav_module         modules/mod_dav.so
LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so
LoadModule php5_module        modules/libphp5.so

The following is added at the end of httpd.conf per the Subversion installation notes.

#
# Subversion repository location
#

<Location /svn/repos>
     DAV svn
     SVNpath /opt/svn_repo
</Location>

Once all this has been done, then firing up Apache (apachectl start) should bring up the httpd daemon and all modules without complaint.

Why Did I Build Everything?

I'm sure I'll get comments and questions about using Fink or DarwinPorts to install everything. So let me answer those comments up front. After looking at Fink I didn't find it particularly 'professional'. Open source providers have a warped sense of humor (Fink, Gimp, even Subversion...) that doesn't go over too well in the professional world. I know that Fink is German for fench, a bird, but the name in English is not too complimentary. That and the fact I found a lot of mixed comments regarding the effectiveness of Fink under MacOS X. I did install DarwinPorts and attempted to update Ruby with it, but the repositories it decided to hit were so slow that after waiting over 20 minutes for port to pull down the necessary modules I killed port and just grabbed the tarballs. At least, with tarballs, I have a very high degree of confidence that they will configure, build, and run as intended.