*: #include <lib>/header.h (stage 2)
*: Compiles fully in C++ (stage 1)
*: Proper use of extern (stage 1)
-*: Minimal linkage, explicitly specify (stage 2)
+*: Minimal linkage, explicitly specify (stage 1)
*: Platform specific files are suffixed as to allow glob macros to add to target (.windows, .unix) (stage 1)
*: condor specific macros are located under build/cmake (stage 1)
+{section: Installing}
+So a big departure from before is the elimination of release_dir and the addition of ye-olde install target with a prefix. For my testing I have all of my paths and what not set against a softlink which allows me to shift amongst multiple versions of condor. Then I run cmake appending a prefix location:
+
+{code}
+cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/condor/x.y.z ...
+{endcode}
+
+This allows me to test any version of condor and maintain those binaries for posterity.
+
+{section: Testing}
+The code has been restructured so *all* things test related are bundled under a single target, and all binaries relating to that target set their output to condor_tests.
+
+{code}
+make tests
+{endcode}
+
+Once built you can run all the batch tests as before.
+
{section: Packaging}
CMake's compliment, CPack, supports a large number of packaging types which can be found {link: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators here}, and it is currently in its infancy in the code base. There are two targets which are created when you include(CPack):
@@ -75,8 +93,6 @@
make package_source
{endcode}
-The road ahead is to create a stub'd out CPackOption.cmake.in file and use cmakes configure options to fill in the gaps based on the target platform and environment, thereby reducing the cruft in the master CMakeLists.txt and providing the wiz-bang feature of platform specific package generation.
-
{section: TODO}
see Ticket #779 #1248
