HTCondorWiki: Build Modernization

 {section: Introduction }
-This wiki page contains information regarding build modernization and consolidation.
+This wiki page contains information regarding build modernization and consolidation.  For details on progress see Ticket #779
 
 {section: Goals and Objectives }
 The goal of updating the condor build mechanism is far more reaching then using the latest wiz-bang tool to build code, and is meant to address the following issues:
@@ -19,89 +19,6 @@
 
 *: *CMake - winner:* CMake is widely adopted in the open source community as a x-platform replacement for auto-tools style builds.  It has it's own Macro-style syntax, but unlike the afore mentioned tools it is a generator similar to Imake and it works with existing tools (make, visual studio).  Another powerful tool in the "CMake warchest" is CPack, which allows for various methods of packaging, across multiple OS distributions.
 
-{section: Plan and phases}
-
-*[Completed] Stage 1: Feasibility* 9/25/09
-
-	Estimated: 	~1 Month - likely less
-	Time Elapsed: 	~1.2 Months
-
-	X - Setup existing environment build and analyze.
-	X - Create full configuration (auhtmlonf-cmake)
-	X - Build for linux and Windows
-	X - Simplify build files (done through cmake macros and updated file extensions .unix .linux .window)
-	X - Develop plan for dealing with externals
-		- Currently the plan is to stage uw-externals prior to building and update include and link paths to this loc by default.  (everything is external)
-		- This greatly simplifies the build process and cleans up the questions of who does "what" "when"
-	X - Build all code with c++ compiler cleanup non-ansi C-code
-	X - Analyze packaging options
-	    CPack will likely meet our needs and eliminate separate steps
-	X - Eliminate unnecessary linkage where possible.
-
-    tools
-        <tbd>...
-    daemons
-        procd ...
-    libs
-        ccb
-	cedar
-	classad_analysis
-	classad.old
-	daemon_client
-	daemon_core
-	privsep
-	procapi
-	sysapi
-	tt
-	utils
-    tests
-        <tbd>
-    include
-        <previous condor_include>
-    scripts
-        <tbd>
-    examples
-        <tbd>
-    <release_dir>
-        ...
-
-	Analysis:
-
-	I was surprised at the levels of "over complexity" within the builds and code dependencies.  So in my work going forwards, my primary goal is to simplify.
-
-	I believe that a cleaner structure would help for future open source progress.  IMHO it should easy for a developer / researcher to obtain the source, build, and install a package.  Also the directory structure
-should be easily to follow and navigate.
-
------
-
-*[In Progress as of 11/14/09] Stage 2: Evaluation, Adoption, & Continuation*
-
-	Estimated: 	~1 - ? Months
-	Time Elapsed: 	1 week
-
-	X Cleanup and cruft and provide tracking branch for UW. (origin/CMAKE)
-	X Setup an wiki page
-	- Have an evaluation with UW and RedHat folks
-		- Try to gain critical feedback.
-	- Continued conversion, and merge out regularly
-        *Develop a test plan methodology (RH & UW)
-	- Establish auto-builds (either through NMI or hudson)
-
------
-
-*Stage 3: Full Parallel Build, Test, and Packaging (Last Month)*
-
-        - Full build and test should be able to run from parallel branch. (Propose switch over.)
-	- Establish full unit testing examples along-side, you pretty much get this for free (CTest + boost::test)
-	- Establish packaging using CPack for *all platforms.
-		- Windows may have multiple forms of distribution according to GregT (.zip .exe .msi ...)
-		- Do we "need" to support .msi? why?
-
-------
-*Stage 4: Proper cleanup (optional/on-going task)*
-
-        - start to move the code so #ifdef's are isolated to a bottom layer. The code should never have #ifdef's above a certain point as it simply should not care.  This eliminates deps, and allows for easier code refactoring.
-
 {section: Getting Started }
 1.) You will need to obtain CMake 2.6 or > for the target platform you are working on.