Page History

Turn Off History

Introduction

This wiki page contains information regarding build modernization and consolidation.

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:

Possible Options

If we use the afore mentioned goals as hard requirements, then it eliminates a lot of possible choices, and only a couple remain:

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.

Getting Started

1.) You will need to obtain CMake 2.6 or > for the target platform you are working on.

2.) Checkout origin/CMAKE, for windows you will need git 1.6.4 or greater.

2.5) Windows only: Because the temporary structure is softlinks to the original files, this causes an issue on windows. So for the time being you will need to flatten the linking using cygwin.

cp -r -L new_build new_build_win (I'm debating on eliminating the softlinks)

3.) Because the build expects that you have certain pre-reqs installed and defaults to a clipped build (atm). You will likely need to install the default set of clipped && proper libraries. On windows this means staging the externals into a location until I can get around to writing a pre-configure script.

4.) Navigate to CONDOR_SRC/src/new_build

5.) cmake ./CMakeLists.txt

6.) make || open the visual studio project & build If you wish to see the native output type make VERBOSE=1

Contributing

All of the updated cmake files exist under src/new_build and are open to contribution. The current branch tracks against master(7.5 series) and all files under new_build are a series of softlinks against the originals to allow for easy merge-outs, and to allow for parallel builds in case it is needed. There are a substantial number of changes and cruft removal in this branch so there may need to be a bit of work to get the old build to function in this new branch, as I have not made it a priority atm.

Conventions

Packaging

CMake's compliment, CPack, supports a large number of packaging types which can be found here, and it is currently in its infancy in the code base. There are two targets which are created when you include(CPack): 

make package
make package_source

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.

TODO

Links

CMake Official Documentation

Google Code Search for open source examples