This document is out of date. It describes how things were done in the configure/imake work. In the cmake world things are different. I've done some work to update it (2011-8-28), but there are almost certainly errors.
-{section: Adding a new external package to condor}
+{section: Adding a new external package to HTCondor}
This document describes how to add a new external package to the
-Condor build. There are a number of elements to this task which are
+HTCondor build. There are a number of elements to this task which are
described below:
*: Packaging the external so it can be built by the build system
*:: Setting up the source tarball
@@ -21,7 +21,7 @@
*: Dealing with externals caches
Before getting into the specifics, here's the 10,000 foot view of
-how the Condor build system deals with externals:
+how the HTCondor build system deals with externals:
*:The actual source tarball is hosted on a public web server.
*:cmake decides which externals we need. The version is part of the cmake information for the branch.
@@ -88,7 +88,7 @@
{section: Packaging the external so it can be built by the build system}
-Each external package used to build Condor lives in a unique
+Each external package used to build HTCondor lives in a unique
directory as part of the =externals= directory tree. The basic
directory layout of =externals= is as follows:
@@ -126,7 +126,7 @@
a Windows specific script in the form =build_[package-name].bat=.
Optionally, there may be patch file(s) which include modifications
-we had to make to the package to get it to work with Condor.
+we had to make to the package to get it to work with HTCondor.
Each of these things are addressed in the following sections...
@@ -171,14 +171,14 @@
*: *Local builds* Place the tarball directly in the external's directory. Modify the package's CMakeFiles.txt, looking for ExternalProject_Add. Inside that function call, comment out the "DOWNLOAD_COMMAND" line. Comment out the "URL" line and add a new one that looks like "URL /full/path/to/my/tarball.tar.gz". This will only work on your localhost. You cannot use a relative path in the URL. *Do not push any commits that contain the full tarball to the public git repository.*
-*: *Local webserver* Place the tarball at some other ftp or http location. Your CS web page ({link: http://pages.cs.wisc.edu/~username http://pages.cs.wisc.edu/~username) or the temporary directory under Condor's anonymous ftp server are possibilities. Then edit the CMakeLists.txt to load the unusual location. You'll be changing the DOWNLOAD_COMMAND and URL arguments to ExternalProject_Add.
+*: *Local webserver* Place the tarball at some other ftp or http location. Your CS web page ({link: http://pages.cs.wisc.edu/~username http://pages.cs.wisc.edu/~username) or the temporary directory under HTCondor's anonymous ftp server are possibilities. Then edit the CMakeLists.txt to load the unusual location. You'll be changing the DOWNLOAD_COMMAND and URL arguments to ExternalProject_Add.
*TODO: adesmet's edits end here*
{subsection: Making the build script}
-When the Condor build is trying to build your external, first it
+When the HTCondor build is trying to build your external, first it
will create a temporary sandbox build directory. The
[name]-[version].tar.gz will be downloaded and untarred into the sandbox. Then, the
=build_[name]-[version]= script will be invoked with the
@@ -232,7 +232,7 @@
path stored in =$EXTERNALS_INSTALL_DIR=) is guaranteed to
exist, so you don't need to worry about =mkdir -p=.
-If your build script wants to know things that the Condor build
+If your build script wants to know things that the HTCondor build
system determines at run-time (for example, what globus flavor we're
trying to build), it can source the file specified in
=$EXTERNALS_CONFIG= (details on sourcing this file below).
@@ -254,7 +254,7 @@
*YOUR BUILD SCRIPT MUST BE PLAIN OLD BOURNE SHELL!!!*.
Do *NOT* use any bash syntax, since it won't work on all 15+
-Condor platforms. For example, =source= is not portable across
+HTCondor platforms. For example, =source= is not portable across
all versions of bourne shell. The correct way to include this file in
your build script is to use:
{code}
@@ -373,7 +373,7 @@
Once your package is setup in the externals tree and the build
-script is ready, you've got to tell the Condor build system about the new
+script is ready, you've got to tell the HTCondor build system about the new
package. There are a few separate places that this needs to happen.
@@ -450,17 +450,17 @@
**requirement levels**
There are three requirement levels, and they determine how
-dependent Condor is on an external. The levels are =soft=,
+dependent HTCondor is on an external. The levels are =soft=,
=hard=, and =optional=. The =soft= level is the
most common and is likely what you need to specify. It means that
-Condor can compile and operate just fine without the external. When
+HTCondor can compile and operate just fine without the external. When
=configure= is run it will look for =soft= requirements,
but will only give a warning if they are not available. This is in
contrast to =hard= requirements, which are always
-required. Condor either will not compile or run without them. They
+required. HTCondor either will not compile or run without them. They
MUST be present. Not being present will cause =configure= to
-fail. You want to avoid adding =hard= externals to Condor. The
+fail. You want to avoid adding =hard= externals to HTCondor. The
third level, =optional=, is just as uncommon as =hard=,
if not more. It operates almost exactly as =soft= with one
exception: there is a =--with-soft-is-hard= option that can be
@@ -496,8 +496,8 @@
way, we have the full path to the =lib= and =include=
directories for the external, and each of those =make=
-variables can be used in regular Condor =imake= input files so
-that the Condor build can use the external.
+variables can be used in regular HTCondor =imake= input files so
+that the HTCondor build can use the external.
**config/config.sh.in**
@@ -505,7 +505,7 @@
=configure= into =config/config.sh=. The full path to
this =config.sh= file is passed into the
-=externals/build_external= script by the Condor build system,
+=externals/build_external= script by the HTCondor build system,
which in turn sets it as the =$EXTERNALS_CONFIG= environment
variable. This way, the package-specific build scripts can use
information that =configure= discovers if that information is
@@ -514,7 +514,7 @@
gahp external needs to know where the globus external was
installed, and what "globus flavor" was built. The blahp external also
needs to know if the platform we're on is trying to build a
-statically-linked version of Condor or not. So,
+statically-linked version of HTCondor or not. So,
=config/config.sh= defines the following variables:
{code}
...
@@ -548,13 +548,13 @@
various =make= variables have been set in the files in
=config=, there are a few minor changes to the =imake=
-input files themselves that need to be made so the Condor build knows
+input files themselves that need to be made so the HTCondor build knows
about the external. In particular, the =src/Imakefile= needs
to know about your external.
To do this, all you have to do is add a new =ext_target= to
the file. This magic =imake= rule handles all the details of
-ensuring the Condor build depends on your external, and that
+ensuring the HTCondor build depends on your external, and that
=externals/build_external= is invoked to build your external at
the appropriate time. This target takes two arguments, the package
name (which should be held in the =make= variable
@@ -598,21 +598,21 @@
ext_target(EXT_FOO_VERSION,$(EXT_TRIGGER)/$(EXT_BAR_VERSION) $(EXT_TRIGGER)/$(EXT_BAZ_VERSION))
{endcode}
-Finally, there's the tricky subject of exactly how the Condor
+Finally, there's the tricky subject of exactly how the HTCondor
=imake= system should use your external and integrate it with
-the rest of the Condor source. Eventually we'll have a better answer
+the rest of the HTCondor source. Eventually we'll have a better answer
for that question here. For now, if it's not totally obvious, just
talk to someone else on the staff and try to come up with something
good. When in doubt, ask Derek.
Once all this is done, you're in a position to fully test your new
-external with a Condor build. You'll have to re-run =autoconf=
+external with a HTCondor build. You'll have to re-run =autoconf=
to generate =src/configure= and re-run the
=src/configure= script itself. After that, a top-level
=make= inside =src= should be all you need to see your
external package built. Once your external build is working and the
-Condor source sees and uses the new external, you're ready to commit
+HTCondor source sees and uses the new external, you're ready to commit
your changes to git.
@@ -620,7 +620,7 @@
{section: Dealing with externals caches}
-The Condor build system allows built externals to be stored outside of your immediate build tree. These external caches can be shared across multiple build locations, greatly reducing the time to do a fresh build of Condor. This is why changing anything in how an external is built requires you to create a new version of the external.
+The HTCondor build system allows built externals to be stored outside of your immediate build tree. These external caches can be shared across multiple build locations, greatly reducing the time to do a fresh build of HTCondor. This is why changing anything in how an external is built requires you to create a new version of the external.
The cache has one directory per package and version number.
