Transcript Source Code and Build Processes

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
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
linux32_rh5.4_gcc4.1.2_shared
win64_vs10.0_shared_d
win32_vs8.0_shared
Java builds
●
●
jdk_1.6.0
jdk_1.7.0
- Linux static release build
- Linux static release build
- Windows MD shared debug build
- Windows MD shared release build
- Red Hat 5.4 builds with Java 1.6
- Red Hat 6.3 builds with Java 1.7
Project Structure
cpp
src
include
doc
test
bin
java
app
example bld
win32_vs8.0_shared
lib
src
bld
lib
jdk_1.6.0
jdk_1.7.0
win64_vs10.0_shared
linux32_rh5.4_gcc4.1.2_shared
linux64_rh6.3_gcc4.4.6_shared
Note: For brevity not all build flavors for C++ are shown.
doc
test
example
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
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
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
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
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
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
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