Argyll Compiling

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 tools. 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.

Check your development environment:

Check you have one of the supported development environments listed, and that your shell is configured to have access to the development tools.

On Linux, check that the appropriate development packages are installed:

    jam: Program construction tool, similar to make [If available - downloadable from the ArgyllCMS website]
    gcc C compiler
    Development files for libX11
    Development files for libXdmcp
    X.Org X11 libXext development package
    X.Org X11 libXxf86vm development package
    X.Org X11 libXinerama development package
    X.Org X11 libXrandr development package
    X.Org X11 libXScrnSaver A.K.A. libxss-dev development package

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 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.

Also on Linux and OSX you may have to make sure that certain environment variables such as HOSTTYPE are exported, so that other programs can see them.

On newer Linux systems that make use of versions of the ar utility that default to so called "deterministic builds" you should set the JAM_NEW_GNU_AR_OPTIONS environment
variable so that the ar U option is set:

export JAM_NEW_GNU_AR_OPTIONS=true

Not doing this will cause libraries to be re-built all the time.

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, or the makeall.ksh shell script file or the makeall.bat file can be used to 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.

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.

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, VC++ 9.0 and VC++ 10.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, 9 or 10 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 have succeeded in cross compiling for Win64 using x86_64-w64-mingw32-gcc, but currently the Jambase isn't setup for cross compilation and I used a hack to build the native executables with a native compiler before invoking the usual Jam compilation in the cross environment.