*: Place the tarball at some other ftp or http location. Your CS web page or the temporary directory under Condor's anonymous ftp server are possibilities. Then edit the CMakeLists.txt to load the unusual location.
*TODO: adesmet's edits end here*
-In either case, ensure you move the tarball to the official externals location and update the =URLS= file before pushing your changes.
-
-{subsection: Making the URLS file}
-
-The =URLS= file is a simple text file containing the URLs of the source tarballs of the external. Normally, there's only one tarball, but a couple externals require several. Each URL should appear on a separate line.
-All of the externals are hosted on parrot.cs.wisc.edu, and the URLs should look like this:
-
-{code}
-http://parrot.cs.wisc.edu/externals/krb5-1.4.3.tar.gz
-{endcode}
-
-If the tarball contains files that aren't publicly releasable, there's a restricted directory:
-
-{code}
-http://parrot.cs.wisc.edu/externals-private/krb5-1.4.3.tar.gz
-{endcode}
{subsection: Making the build script}
@@ -628,47 +612,11 @@
{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 and users, greatly reducing the time to do a fresh build of Condor. This is way changing anything in how an external is built requires you to create a new version of the external.
-
-The cache consists of the following directories:
-{code}
-externals/build
-externals/install
-externals/triggers
-{endcode}
-If you don't use an external cache, these directories will be created in your build directory.
-
-There are three situations where you'll see an external cache:
-*:Your own cache
-*:The cache in AFS at UW-CS
-*:The cache in NMI
-
-{subsection: Your own cache}
-You can specify your own externals cache directory using the =--with-externals= command-line option to configure like so:
-
-{code}
-./configure --with-externals=/scratch/externals-cache
-{endcode}
-
-{subsection: The cache in AFS at UW-CS}
-The Condor team has a shared externals cache on AFS in =/p/condor/workspaces/externals=. The tree is set up with =@sys= links to separate files by platform. If you don't use the =--with-externals= option to =configure= and this directory exists, =configure= will use this cache automatically. If you don't want to use this cache, you can explicitly disable it like this:
-
-{code}
-./configure --with-externals=`pwd`/../externals
-{endcode}
-
-{subsection: The cache in NMI}
-We keep an externals cache on all of the machines in the NMI Build and Test facility. By default, the Condor glue scripts for NMI don't use the cache. You can enable use of the cache with the =--use-externals-cache= option to =condor_nmi_submit=. The automated builds all do this.
-
-{subsection: New externals and caching}
-
-One of the fundamental assumptions of the externals cache is that a particular external version will never change. Whiling you're preparing a new external or external version, this will not be true. Thus, you need to be careful not to pollute any shared caches with old revisions of your new external.
-
-The easiest way to do this is to not use any shared external caches. If you're using a machine at UW-CS, you can explicitly disable use of the cache in AFS. The downside to this is that you have to build all of the externals in your local build space. You can play games with symlinks to minimize this rebuilding.
+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.
-If you do decide to use the AFS cache, you must make sure it has the final revision of your external once you're ready to check it in. You can do so by simply removing the appropriate trigger file in =/p/condor/workspaces/externals/triggers=.
+The cache has one directory per package and version number.
-The externals caches in NMI are trickier. Each machine has a local cache and some platforms have multiple machines. Manually clearing the caches on all of the machines is cumbersome and error-prone. Better to never use the externals cache when developing a new external.
+Externals are, by default, built and stored in /scratch/condor-externals; you can change this default location with something like -DEXTERNAL_STAGE:PATH=/path/to/a/private/directory when you invoke cmake.
{section: FAQS}
