Page History

Turn Off History

Overview

As of 7.5.5, Condor uses cmake to configure the build. For instructions on building Condor prior to that, see "Building Condor prior to 7.5.5" below.

Space Needed for a Full Build

You may need around 6 Gigs to build a releasable package of Condor. If you just want to build eveything up to the releasable package, then you might need only 3 Gigs or so.

Getting the source

Directly from the GIT repository

If you reside on the CSL networks and/or have access to our GIT repository, then follow ManagingCondorSourceTreesWithGit up to but not including the section entitled Working on a single person project.

Ensure you have checked out and are about the build the correct branch you want.

If you'd like to perform the full build process, producing the sort of package one downloads from our website with the source, then you should grab the tarball of man pages make public needs from AFS: 

# sitting at the toplevel with src/ config/ externals/ etc....
% cp /p/condor/workspaces/externals/bundles/man/current/man-current.tar.gz externals/man/current

From our download pages

If you are building Condor sources from our download page. Then download the source tarball, it'll have a name similar to condor_src-X.Y.Z-all-all.tar.gz. X.Y.Z represents the version of Condor for which the source creates.

When you untar the source tarball, what you get is remarkably similar to what one would check out of GIT and should be directly buildable. You will have available in the externals directory the tarball of manual pages needed by our packaging scripts.

Required Prereqs

One needs, as a good start these revisions, or later, of these tools: cmake 2.8.3, wget-1.9.1, tar 1.14, autoconf-2.59. For a more complete list, run nmi_tools/glue/SubmitInfo.pm and look at the listed prereqs for a platform as similar to the one you are using as possible.

Externals required for Building

Condor may use a sizable collection of externals which implement various feature sets for Condor. Some examples are Kerberos, OpenSSL, Globus. There are only a small number of externals that Condor absolutely requires to build; these are usually quite portable. There are two ways to link with external packages, using the blessed and patched versions of the packages from the UW Condor externals collection, or using the native libraries installed on the build machine. We'll call these the 'UW' way and the 'proper' way. To get externals the UW way, Condor sources include an externals/ directory which contains URLs to locate the required externals and patches to be applied. To get externals the 'proper' way, you'll need to use your system's package manager to install the necessary development libraries.

Configure your build

The common options for configuring Condor to be built the 'UW way' are passed to cmake by running configure_uw. This will configure the build to use the UW externals collection rather than local system libraries.

Additional arguments to cmake may be passed on the command line of configure_uw. On most common platforms, no additional build options are required. For other platforms, there are several ways to explore the build options:

Building your source

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

install

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

package

make package will produce packages similar to what you can download from the UW download site for the machine upon which you are building.

Running the developer test suite

make tests will prepare Condor for testing, but it will not run the tests. To run the tests, use ./batch_test.pl -b.

Building Condor prior to 7.5.5

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

Confirm the build environment

The README.building does a decent job of covering this, but usually you'd basically need these revisions, or later: wget-1.9.1, tar 1.14, autoconf-2.59.

Required Prereqs

One needs, as a good start these revisions, or later, of these tools: wget-1.9.1, tar 1.14, autoconf-2.59. If you are on a recent linux-flavor machine, building Condor is pretty easy, the farther you get into the fringe architectures, like ia64 hpux 11, the more prereqs you may need. Luckily, the configure output is pretty good about telling you about any tools you need to update.

Space Needed for a Full Build

You may need around 6 Gigs to build a releasable package of Condor. If you just want to build eveything up to the releasable package, then you might need only 3 Gigs or so.

Getting the source

Directly from the GIT repository

If you reside on the CSL networks and/or have access to our GIT repository, then follow ManagingCondorSourceTreesWithGit up to but not including the section entitled Working on a single person project.

Ensure you have checked out and are about the build the correct branch you want.

If you'd like to perform the full build process, producing the sort of package one downloads from our website with the source, then you should grab the tarball of man pages make public needs from AFS: 

# sitting at the toplevel with src/ config/ externals/ etc....
% cp /p/condor/workspaces/externals/bundles/man/current/man-current.tar.gz externals/man/current

From our download pages

If you are building Condor sources from our download page. Then download the source tarball, it'll have a name similar to condor_src-X.Y.Z-all-all.tar.gz. X.Y.Z represents the version of Condor for which the source creates.

When you untar the source tarball, what you get is remarkably similar to what one would check out of GIT and should be directly buildable. You will have available in the externals directory the tarball of manual pages needed by our packaging scripts.

Externals required for Building

Condor may use a sizable collection of externals which implement various feature sets for Condor. Some examples are Kerberos, PostgreSQL, Globus. Condor sources include an externals/ directory which contains URLs to locate the required externals and patches to be applied. There is only a small number of externals that Condor absolutely requires to build, these are usually quite portable.

Configure your build

If you are building a new version of condor with cmake, see the new build instructions

build_init 

% ./build_init

On "native" platforms

 On these platforms, hppa_hpux_11, ia64_rhas_3, ppc64_sles_9, ppc_aix_5.2-pl5, ps3_ydl_5.0, sun4u_sol_5.9, x86_64_deb_5.0, x86_64_rhap_5, x86_64_rhas_3, x86_deb_4.0, x86_deb_5.0, x86_macos_10.4, x86_rhap_5, x86_rhas_3, 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 Condor 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 Condor 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

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.