Installing the toolchain

Monotone's makefile has to be generated using special GNU tools. Tiger (OS/X 10.4) does not have the required versions of these tools in the standard installation, though XCode 2.4.1 comes with an adequate version of the C++ compiler itself (older XCode versions have been known to be buggy).

One way to get and build the latest versions of GNU tools is to get them from the MacPorts (previously known as Darwin Ports) project. Install the porting application from http://svn.macports.org/repository/macports/downloads/ and it will put a program called "port" into your /opt/local/bin directory. When you run this program as an administrator, it installs and builds the latest versions of GNU tools into that same directory.

(if /opt/local/bin is not in your path, you can add it in a terminal shell by typing PATH=/opt/local/bin:$PATH)

Once you have installed the port tool, run the following commands (enter your password when prompted):

% sudo port install gettext
% sudo port install autoconf
% sudo port install automake

Getting the source

Sometimes there is no pre-built binary of monotone on http://monotone.ca/ that is compatible with the version the development server is running. This means that if you want to synchronize and participate with the latest sources you will have to first build your own executable from a snapshot (.tar.gz file).

It's not actually that hard, and the instructions in the INSTALL file which come in the archive will walk you through it. When you install boost it may not be put into your library path, but you can tell the configure script that generates the makefiles where it is:

% ./configure CPPFLAGS="-I(BOOSTPATH)/boost_1_32_0" LDFLAGS="-L(BOOSTPATH)/boost_1_32_0/libs"

If the executable you generate seems unreasonably large (over ~10 megabytes in size) then run strip monotone (or strip -S to keep basic symbols for debugging).

Once you have a working monotone, then the following commands will let you grab the current development branch off the server:

% monotone --db=mt.db db init
% monotone --db=mt.db --key="" pull monotone.ca net.venge.monotone
% monotone --db=mt.db --branch=net.venge.monotone checkout monotone-sources

This will take a while to download. Once it comes you will have to build it (in the same way described above). But when you pull down this source it will not have a configure script, so you will need to run autoreconf --install to generate it.

Using Xcode

The GNU tools do not have an option to generate a .xcodeproj alongside your makefile (the way Qmake can). If you're just building, stick with the command line. But if you're going to be doing editing, building, and debugging, you'll probably want to use Xcode, so:

create a fresh project
add a new "External Target" and make sure it points to /usr/bin/make
add a new "Executable" and make sure it points to wherever monotone is built
manually populate the project with files

Using Xcode as a debugger can be tricky. When you set a breakpoint in the UI it might not be able to find the address. Try running gdb on the command line as a sanity check:

% gdb monotone
(gdb) br cpp_main
(gdb) run

If you don't break at the entry point, then something is wrong with your debug build. However, if this works, then go to the debugging console in Xcode and try setting a breakpoint at cpp_main. After that the IDE may start setting breakpoints correctly. If you want to check on the status of your breakpoints, then in the debugging console type:

(gdb) info br

It shouldn't say "" for the addresses.

Things to look out for

As of 2006-01-22, boost from darwinports is not linked with the correct install_name (darwinports bug 5533). Linking statically should still work, or compile it yourself
If you are linking to boost statically and ./configure can't see the libs, try running ranlib *.a on the Boost library files to update the archive indexes.
As of xcode 2.3 (gcc build 5341), -ggdb will generate dwarf debugging symbols. The size of a compile dir will be significantly (4x?) smaller with dwarf, so -ggdb is recommended. Note however that Shark doesn't seem to handle dwarf debugging symbols (as of 4.3.3) - you might want to explicitly give -gstabs.

Building a universal binary

. To create a universal binary, first you'll need to create fat boost libraries. Build two separate sets of boost static libraries, one with -arch ppc and one with -arch i386. Then use lipo -create to produce a set of single .a files (use file libboost_foo.a to check that it worked). I then put header files in /usr/local/stow/boost-1.33.0-fat/include/boost and the .a files in /usr/local/stow/boost-1.33.0-fat/lib.

For configure, I've used:

./configure CFLAGS="-O2 -mdynamic-no-pic -ggdb -gfull -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386" CXXFLAGS="-O2 -mdynamic-no-pic -fno-threadsafe-statics -ggdb -gfull -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386" --enable-static-boost=/usr/local/stow/boost-1.33.0-fat CPPFLAGS="-pipe -I/usr/local/stow/boost-1.33.0-fat/include" LDFLAGS="-L/usr/local/stow/boost-1.33.0-fat/lib -dead_strip" --disable-dependency-tracking

You should then be able to just make, though note that distcc doesn't seem to work with multiple -arch flags, since it uses the -E gcc option. The final output binary will be massive, so strip -S is recommended for distribution. An alternative approach to making a universal binary is to just build two separate monotone binaries, then lipo -create to stick them together.

The -fno-threadsafe-statics works around a Apple gcc bug (4227885) that causes dramatic performance decreases accessing static variables. -dead_strip and -gfull are used to avoid linking in code that isn't used, reducing the binary size.