Page History
- 2012-Nov-13 17:04 adesmet
- 2012-Nov-13 15:18 adesmet
- 2012-Jun-27 14:33 jfrey
- 2012-May-24 11:01 kronenfe
- 2012-May-24 10:49 kronenfe
- 2012-May-24 10:40 kronenfe
- 2012-May-24 10:38 kronenfe
- 2011-Jun-08 11:39 jfrey
- 2011-Jun-07 13:35 adesmet
- 2011-Jun-07 13:33 adesmet
- 2011-May-31 11:55 kronenfe
- 2011-Mar-02 10:12 nleroy
- 2011-Jan-27 15:59 nleroy
- 2011-Jan-19 13:54 nleroy
- 2011-Jan-04 16:21 danb
- 2010-Dec-06 09:18 nwp
- 2010-Dec-06 09:16 nwp
- 2010-Mar-03 13:37 tannenba
- 2009-Nov-06 12:56 psilord
- 2009-Jan-15 15:38 michaelb
- 2009-Jan-15 15:15 michaelb
- 2009-Jan-15 15:07 michaelb
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.
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 entitledWorking 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 tocondor_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 anexternals/
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 instructionsbuild_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:
- --with-arch This can only be one of: I386, X86_64, PPC, ALPHA, CONDOR_PPC, IA64, CONDOR_PPC, HPPA, SUN4X, UNKNOWN_ARCH
- --with-os 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 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.
Building your source
While there are many targets tomake
, 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.