Overview

These instructions are for building HTCondor versions prior to 7.5.5. If you want to build HTCondor 7.5.5 or later, see BuildingHtcondorOnUnix.

Configure your build

build_init 

% ./build_init

On "native" platforms

 On these platforms, configure should just "work": 

% ./configure

On "non-native" platforms

On anything other than the above, *but in the same family*--e.g., ia64_rhas_4, you probably want to try and build the most minimal HTCondor build possible. Configure will mostly detect the right things about the platform identification. If this builds, then you can start turning on more feature as you need them and rebuilding. 

% ./configure  \
        --disable-proper \
        --without-globus \
        --without-krb5 \
        --disable-full-port \
        --without-voms \
        --without-srb \
        --without-hadoop \
        --without-postgresql \
        --without-curl \
        --with-pcre \
        --disable-quill \
        --disable-gcc-version-check \
        --disable-glibc-version-check \
        --without-gsoap \
        --without-glibc \
        --without-cream \
        --without-openssl

If ./configure has problems identifying your machine

If everything seems to work, but the package name on the tarballs are wrong after you build them, then you'll want to use --with-platform=*os*-*arch*-*distro* as in --with-platform=linux-ia64-sles8.

In the case where ./configure just goes very very wrong, you may have to supply more arguments to configure which control deeper compilation aspects. These arguments are somewhat fiddly since they often define actual preprocessor symbols that the HTCondor code uses for conditional compilation. This means that some of these arguments can not be specified arbitrarily. It may be possible if you are "close" to a unix family we already support that you can select a combination of these that will allow the build to be completed.

These are:

Building your source

Before 7.5.5, HTCondor used configure + imake to generate makefiles.

While there are many targets to make, I will only describe the two that are most likely what you want.

release

make release will make a set of executable binaries and place them in release_dir/. They will be dynamically linked and suitable for testing by pointing a $(RELEASE_DIR) at it from a condir_configure file.

public

make public will produce packages similar to what you can download from the our download site for the machine upon which you are building. If you ever see two or more dashes in a row in the file name, it means they are named wrong and you might have to use --with-platform on configure and try again.

Building the tests

$ cd src/condor_tests
$ make

Running the tests

$ cd src/condor_tests
$ ./batch_test -b -c

Running the tests again

Running the test suite leaves files and directories in the src/condor_tests directory that prevent the tests from running again. To solve this, either remove and recreate the src/condor_tests directory and build the tests again (as above), or (this doesn't remove everything, but enough to re-run the tests): 
$ cd src/condor_tests
$ rm -fr TestingPersonalCondor
After either of these, you can re-run the tests as above.

Running the developer test suite

Cached Externals

Builds by default cache the externals in /scratch/condor-externals. If you're sharing the machine with others, you may collide and have problems. Solution, add 

-DEXTERNAL_STAGE:PATH=/path/to/a/private/directory
to your invocation of configure_uw