If you do not already have Jam 2.5 on your system or if it is not
available as an installable package, 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
source archive of Jam is available as a .zip here
for MSWin, or as a .tgz for OS
X and Linux.
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.
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
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.
You may have to check that your shell environment variable $HOSTTYPE has been exported, so
that Jam can know if it's 64 bit or not,
and look for libraries in the right place. You can fix this permanently in your shell .initialization file (ie. ~/.profile, ~/.bashrc etc.).
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.
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.