{section: Overview}
-This document describes a few common ways Condor may be built. Those ways
-are as a Condor developer normally would on machines we have at UW-Madison,
-a developer who might download the Condor source, and how to produce *very
-minimal* builds of Condor for porting purposes.
+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.
+
+{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.
+
+{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: 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}
+
+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
+*: =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.
+
+
+{section: Building your source}
+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.
+
+{section: 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=.
+
+
+
+
+
+
+
+
+
+
+
+
+
+{section: Building Condor prior to 7.5.5}
+Before 7.5.5, Condor used configure + imake to generate makefiles.
{section: Confirm the build environment}
The README.building does a decent job of covering this, but usually
@@ -154,9 +243,3 @@
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: TODO}
-
-{section: Clipped porting if all else fails}
-{subsection: TODO}
