{section: 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.

{section: 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.

{subsection: 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.

{subsection: 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.


{section: Getting the source}

{subsection: 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:

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

{subsection: From our download pages}
If you are building Condor sources from our
{link: http://www.cs.wisc.edu/condor/downloads-v2/download.pl 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.

{subsection: 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.


{subsection: 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.

{subsection: 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.

{section: Configure your build}

{subsection: Condor versions 7.5.5 and later}

See the new build  {link: https://condor-wiki.cs.wisc.edu/index.cgi/wiki?p=BuildModernization instructions}

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:

*: ccmake
*: cmake-gui
*: cmake -i
*: Use =nmi_tools/glue/SubmitInfo.pm=, which shows the build options that are used to build Condor on a wide variety of platforms in the NMI build system.
*:: To list the platforms that SubmitInfo.pm knows:
*::: =./nmi_tools/glue/SubmitInfo.pm -l=
*:: To list the options for a particular platform
*:::  =./nmi_tools/glue/SubmitInfo.pm <= _platform_ =>=
*:::  Example: =./nmi_tools/glue/SubmitInfo.pm x86_64_opensuse_11.3=
*:: You can also specify a regex:
*:::  =./nmi_tools/glue/SubmitInfo.pm <= _/regex/_ =>=
*:::  Example: =./nmi_tools/glue/SubmitInfo.pm /opensuse/=
*: A minimal configuration:
{code}
./configure_uw \
  -DCLIPPED:BOOL=ON \
  -DPROPER:BOOL=OFF \
  -DWITH_BLAHP:BOOL=OFF \
  -DWITH_BOOST:BOOL=OFF \
  -DWITH_COREDUMPER:BOOL=OFF \
  -DWITH_CREAM:BOOL=OFF \
  -DWITH_CURL:BOOL=OFF \
  -DWITH_DRMAA:BOOL=OFF \
  -DWITH_EXPAT:BOOL=OFF \
  -DWITH_GCB:BOOL=OFF \
  -DWITH_GLOBUS:BOOL=OFF \
  -DWITH_GSOAP:BOOL=OFF \
  -DWITH_HADOOP:BOOL=OFF \
  -DWITH_KRB5:BOOL=OFF \
  -DWITH_LIBVIRT:BOOL=OFF \
  -DWITH_LIBXML2:BOOL=OFF \
  -DWITH_UNICOREGAHP:BOOL=OFF \
  -DWITH_VOMS:BOOL=OFF \
  -DWITH_LIBDELTACLOUD:BOOL=OFF
{endcode}

{subsection: Configuring Condor 7.5.4 and earlier}
{subsubsection: build_init}
{code}
% ./build_init
{endcode}
{subsubsection: On "native" platforms}
On these platforms, configure should just "work":
*:: *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*

{code}
% ./configure
{endcode}

{subsubsection: 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.

{code}
% ./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
{endcode}

{subsubsection: 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:

*: --with-arch _{quote:<}architecture{quote:>}_
This can only be one of:
*:: I386
*:: X86_64
*:: PPC
*:: ALPHA
*:: CONDOR_PPC
*:: IA64
*:: CONDOR_PPC
*:: HPPA
*:: SUN4X
*:: UNKNOWN_ARCH
*: --with-os  _{quote:<}OS Name{quote:>}_
This can only be one of:
*:: AIX
*:: HPUX
*:: LINUX
*:: SOLARIS
*:: DARWIN
*: --with-kernel
Mostly arbitrary, I don't think this is extensively used for conditional
compilation. This will be something like 2.6.9-89.0.7.EL.cernsmp
if on linux.
*: --with-os_version _{quote:<}version{quote:>}_
This can only be one of:
*:: OSX_10_4
*:: OSX_UNKNOWN
*:: AIX5
*:: AIXUNKNOWN
*:: HPUX10
*:: HPUX11
*:: SOLARIS26
*:: SOLARIS27
*:: SOLARIS28
*:: SOLARIS29
*:: FREEBSD[5-7]
*:: LINUX_TAO1
*:: LINUX_TAO_UNKNOWN
*:: LINUX_YD30
*:: LINUX_YD50
*:: LINUX_YD_UNKNOWN
*:: LINUX_GENTOO1.12.11.1
*:: LINUX_GENTOO_UNKNOWN
*:: LINUX_FC[1-N]
*:: LINUX_RH72
*:: LINUX_RH80
*:: LINUX_RH9
*:: LINUX_SLES81
*:: LINUX_SLES9
*:: LINUX_SuSE_UNKNOWN
*:: LINUX_DEBIAN40
*:: LINUX_DEBIAN50
*:: LINUX_DEBIAN_UNKNOWN
*:: LINUX_UNKNOWN
*: --with-sysname
This can be arbitrary.


{section: Building your source}

{subsection: Condor versions 7.5.5 and later}

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

{subsubsection: 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.

{subsubsection: 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.


{subsection: Condor versions 7.5.4 and older}
Before 7.5.5, Condor 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.

{subsubsection: 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.

{subsubsection: 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.

{section: Running the developer test suite}

{subsection: Building the tests}
{subsubsection: Condor 7.5.5 and later}

{code}
$ make tests
{endcode}

{subsubsection: Condor 7.5.4 and earlier}
{code}
$ cd src/condor_tests
$ make
{endcode}

{subsection: Running the tests}
{code}
$ cd src/condor_tests
$ ./batch_test -b -c
{endcode}

{subsubsection: 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):
{code}
$ cd src/condor_tests
$ rm -fr TestingPersonalCondor
{endcode}
After either of these, you can re-run the tests as above.

{subsection: 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
{code}
-DSCRATCH_STAGE:PATH=/path/to/a/private/directory
{endcode}
to your invocation of configure_uw