## Compiling the Source Code

If you have downloaded the source code package, then you will need to read the following instructions in order to compile and then run any of the utilities. If you have downloaded one of the platform specific executable package, then the executables don't need to be compiled, and the following instructions are not relevant.

##### First setup JAM:

Argyll makes use of a build system called Jam/MR. Jam is cross platform, highly customizable and flexible. It uses a concise, scalable and platform neutral configuration files, and is fast.

If you do not already have Jam 2.5 on your system, you will need to install it. [It may be available as an RPM for Linux systems.] Jam/MR is available from <ftp://ftp.perforce.com/jam> You'll want to bootstrap it up using its Makefile - see the README file that comes with Jam for more information. You may want to apply the patch jam.patch included in Argyll to jam.c so that it uses the environment variable JAMBASE, and then setting this environment variable to point to the Argyll Jambase. The patch also fixes a non-critical bug that affects building using MingW. Note that building jam results in an executable jam0 that you will want to rename and install in an appropriate place on your system. A pre-patched archive of Jam is available here.

An alternative to the original Jam may be ftjam, which is appears to be backwards compatible with the original Jam/MR.

The Jambase I am using for Argyll is different to the default Jambase provided with Jam and compiled into it, and you need to arrange to use this when you compile Argyll. You can tell Jam to use an alternate Jambase using the -f option, or by setting the environment variable JAMBASE to point to the Argyll Jambase if you applied the Argyll patch to jam. Another method would be to create a shell alias of jam that invokes jam using the -f flag, or to create a script that provides the -f option to point to the Argyll Jambase. Argyll will not build properly if you use the wrong Jambase.

If you are running on Mac OSX, then even though OSX comes with a version of Jam/MR in the development system, you will need to download, build and install a normal version of Jam/MR Version 2.5 or later from perforce, to be able to build Argyll. This is due to Apple changing their version of Jam sufficiently to make it incompatible with normal Jamfiles :-(.

On OSX what I did was to name the "normal" Jam ajam, and then setup a jam shell script to invoke it something like this: "ajam -f~/src/argyll/Jambase $*", and to make sure that my script is ahead of Apples jam in my $PATH. The makeall.ksh script or Makefile will run Jam with the -f flag.

You may also have to set the appropriate environment variable to tell the Jambase which compiler you are using.

##### Then compile Argyll:

Once you've got a working Jam, you simply have to unzip the argyll.zip file, and it will create a top level directory Argyll_VX.X.X, where X.X.X is the version number, and you can then cd into this directory and run jam. For a faster build on a multiprocessor system you may like to use the -j option to do a parallel build, e.g. jam -j3. To install the executables in the bin directory and the sample files into the ref directory, run jam install. To remove everything that has been built, run jam clean. On Linux/OS X you could also just try running make, and the makefile will invoke jam.

Something to watch on the Intel versions of OS X 10.4, is that your shell environment variable $MACHTYPE may be incorrect. On Intel 10.4 it should be i386-apple-darwin8.0, but there are bugs in Apples distribution.

To build a particular sub directory only, cd to the directory and simply run jam, although be aware that the local Jamfile compile time options may be different to those in the top level Jamfile used when compiling from the top.

NOTE that "jam install" doesn't install the resulting binaries in the "usual places", it installs them in the Argyll_VX.X.X/bin directory, and it's then up to you whether you want copy them to somewhere like C:\Program Files\argyll, /usr/bin, /usr/local/bin etc., or simply leave them there.

##### Compile environment on MSWindows:

Setting up a compile environment on MSWindows can be challenging. The simplest approach is probably to install MingW, since it provides both the compiler and the SDK in one package.
I've successfully compiled using Microsoft VC++ 6.0, but I think I remember tweaking some of the header files by borrowing from a latter SDK to be able to incorporate the necessary function calls to access display and color profiles on Win2K and latter, so this may not work "out of the box".

I've also successfully compiled using Microsoft VC++ 8.0 and VC++ 9.0 Express (the free Microsoft compiler) plus the Microsoft Platform SDK February 2008. To get this to work though, I had to create my own batch file to setup the SDK environment variables MSSdk etc., because the batch files provided with the SDK got confused by the presence of VC++6, and didn't notice that VC++8 or 9 was configured.

Note that for some hard to fathom reason VC++ 9.0 refused to install on my Win2K development machine, so I had to install it on a WinXP machine and then copy the installation back to Win2K, and manually complete the installation. There seems to be no reason for this limitation, since the VC++9 compiler/linker etc. seems quite happy to run on Win2K.

I haven't attempted to compile for Win64, and currently the Jambase isn't setup for cross compilation, nor have I tried to setup a native build environment yet on Vista64.