1. Project Source Code Structure and Build Process ● Remember consistency matters as source code structure, build process, and release processes are all intertwined. ● Recommended project tree structures ● Build process structure ● Automated build process ● Deployment

2. Directory Name Mangling ● Dynamically created derived object directories are name mangled to keep all build derived object separated. ● Mangling: – PlatformIntSize_OS_Compiler_LinkType[_Debug] ● Examples: – linux64_rh6.3_gcc4.4.6_shared - Linux static release build – linux32_rh5.4_gcc4.1.2_shared - Linux static release build – win64_vs10.0_shared_d - Windows MD shared debug build – win32_vs8.0_shared - Windows MD shared release build – Java builds ● jdk_1.6.0 - Red Hat 5.4 builds with Java 1.6 ● jdk_1.7.0 - Red Hat 6.3 builds with Java 1.7

3. Project Structure cppjava srcincludebinapplibsrcblddoctest libexampledoctestexamplebld win32_vs8.0_shared linux32_rh5.4_gcc4.1.2_shared win64_vs10.0_shared linux64_rh6.3_gcc4.4.6_shared jdk_1.6.0 jdk_1.7.0 Note: For brevity not all build flavors for C++ are shown.

4. Directories ● src – library source code – sub directories by service or logical function – sub directories for object and dependency files are automatically created by build process ● include – headers for project – sub directories by service or logical function ● apps – project applications – sub directories by executable application ● doc – auto generated doxygen, or javadoc, doxygen configuration file ● bin, lib, and object sub directories below source code locations are automatically created by the build process – bin and lib are for delivery end items

5. Directories Continued ● test – unit test code, sub directories as appropriate consistent levels are helpful ● example – code to demonstrate how to use functionality ● Other directories maybe needed for XML configuration files and other project specific needs ● Keep test code and other things out of source code trees to facilitate source lines of code, SLOC, metrics and to avoid confusion between TADS and contractual developed code

6. Build Process ● bld – project build starting location and location for common build process files – mkcommondefs.mk file for make macro definitions – mkcommonrules.mk rules file for compiling library source code – mkcommonbinrules.mk rules file for creating executable deliverables – mkcommonexerules.mk rules file for unit test code compile each source file into an executable – mkhelp.mk make process help information – makefile – top level make file

7. Build Process Continued ● mkcommondefs.mk – make macro file with platform specific sections and global macros ● Leaf makefiles – in each source directory location – Seldom more than a template which includes the mkcommondefs.mk and a mkcommon...rules.mk rule file – Provisions for extending common build process; should be kept to a minimum for maintenance reasons

8. Build Process Continued ● Java builds are done with ANT – The ANT process is wrapped with make to establish the environment set up – The initial ANT build script and the make wrapper need to reside at, preferably, the same directory, so that relative environment paths created by the make wrapper are correct for the ANT build process ● Need to keep Java and C++ build steps separate if you want to run parallel builds

9. Automated Daily Builds ● Daily builds are run for all platform builds ● Post daily build check report is e-mailed to project leads, CM, test, and others ● Daily build views are automatically removed after a defined period

10. Summary ● Remember consistency matters for maintenance and other software manufacturing process implementations ● After build completion we run a Java application for factory deployment – Copies all platform builds to a structure for testing ● Javadoc and doxygen documentation is created and pushed to a program web site