Project Source Code Structure and Build Process

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: • OS_LinkType_Instr_Debug • Examples: • linux_static - Linux static release build • win32_static_d - Windows MD static debug build • solaris_shared_p_d - Solaris dynamic purify debug build • vxworks_RIC_KERNEL_static – VxWorks RIC target kernel mode static build

3. Project Structure cpp java src include bin app lib src bld doc test doc test example bld lib example linux_shared win32_shared solaris_shared win32_shared_d linux_static solaris_static_d linux_shared_q win32_static vxworks__TGT_MODE_static

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 locataions 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 • 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, preference 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