11 Development Tools: 11.1 Program Builds

Development Tools
11 Development Tools
Software development requires many development tools, such as editors and compil-
ers. Other essential tools include debugger, analysis tools, source code management
tools and documentation tools. These de-
velopment tools are widely available due to (11) Development Tools
the work of FOSS developers, who create
We have variety of Development tools
tools that they themselves need for FOSS FOSS development tools
Developers make a new
Compiler
Debugger
development. The developers then release tool for themselves
Plenty of tools for

Analyzer, profiler
Source code
these tools as FOSS. Since distributed de- distributed development
Based on FOSS
management
Maintaining
development via the
velopment over the Internet is the prima- Internet
GUI-based tools are

compatibility
Localization
Documentation
ry means of FOSS development, develop- increasing, in addition to
conventional CUI-based IDE based on GUI
tools Bug tracking tools
ment tools for this purpose are particularly

extensive. Previously, almost all develop- An Introduction to Free/Open-Source Software
Copyright © 2005,2006, Center of the International Cooperation for Computerization (CICC) All Rights Reserved.
Copyright © 2005,2006, Mitsubishi Research Institute, Inc. All Rights Reserved. 292
Copyright © 2008, University of Puerto Rico at Mayaguez. All Rights Reserved.
ment tools were CUI--based, but the num-

ber of GUI tools has recently increased as
the developer base has grown. This chapter examines basic development tools, fo-
cusing on program development using compiled languages.
11.1 Program Builds

In order to execute a program, it is necessary to create an executable program
from source code. This procedure is called the build process. The build process
for a typical program is described in this
section. Compiler
First, the source code is compiled using a
Process of building software
compiler, which converts the source code Compile
Source code -> object code
into an object code written in machine lan- Link
Set of object code -> executable code
guage. Next, the object code is linked to File describing the process of building software
Makefile
libraries using a linker, in order to create gcc, make, ld

De fact standard tools for FOSS development
an executable program. In FOSS develop-

ment, gcc is frequently used as the com-
piler and ld as the linker. An Introduction to Free/Open-Source Software
The complexity of the build process in-

creases as the software being developed grows
in scale. The FOSS utility make is used to automate the sequence of processes in-
volved in a build. Developers use a makefile to describe the build process. The make
utility automatically reads the makefile during builds. This chapter examines the
gcc, ld, and make tools used for builds.
227
Program Builds
11.1.1 GCC
GCC, which stands for the GNU Compiler
Collection, is a set of compilers. Devel- GCC
opment of GCC was started in 1984 by
gcc (the GNU Compiler Collection)
Richard Stallman. The name originally Development started in 1984 by Richard Stallman
stood for GNU C Compiler, since it was Originally stood for GNU C Compiler
Now stands for GNU Compiler Collection
originally developed as a compiler for the Includes compilers and libraries for C, C++, Objective-
C, Fortran, Java and Ada
C++ compiler g++
C language. The features were later ex- Fortran compiler g77
Java compiler gcj
tended to include other compilers and li- Features
braries, adding support for additional lan- Widely used for commercial and non-commercial
operating systems
Can also be used as cross-compiler
guages beyond C. GCC now includes the C An Introduction to Free/Open-Source Software

compiler gcc, the C++ compiler g++, the

Fortran compiler g77, the Java compiler
gcj and compilers for Objective--C and Ada. The name GNU Compiler Collection
is more appropriate due to the support for diverse languages.
GCC is used as the default compiler for many commercial and non--commercial
operating systems, in addition to FOSS operating systems such as GNU/Linux,
FreeBSD, and NetBSD. GCC can also be used as a cross--compiler and is frequently
used for embedded software development.
11.1.2 Make
Make is a utility for automatic building process. Rules for a build are described in
a file called a makefile. These files prescribe how to compile, link and install pro-
grams. Make executes a build according
to the contents of the makefile. In addi- Make
tion to automating builds, make includes To help manage build PACKAGE = hogehoge
SRCS = $(PACKAGE).c
OBJS = $(SRCS:.c=.o)
features to shorten build times by mini- process
FILES = README Makefile $(HEADS) $(SRCS)
VER = `date +%Y%m%d`
Marking of dependency CC = gcc
mizing the tasks required to update builds. and processing method

CFLAGS = -g -O2 -Wall $(DEBUG)
CPPFLAGS = -I.
.SUFFIXES:
Rules (compile, link, .SUFFIXES: .o .c .cc .f .p
This feature is accomplished by compar- installation, etc.) are

described in makefile
all: $(PACKAGE)
$(PACKAGE): $(OBJS)
$(LD) $(LDFLAGS) $(OBJS) -o $@ $(LDLIBS)
ing the modification time of the source files Autotools convenient for
automatic generation of
$(OBJS): $(HEADS) Makefile
.c.o:
rules
$(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@
with the last time the derived files were up- Build optimization
.cc.o:
.f.o:
$(CXX) $(CXXFLAGS) $(CPPFLAGS) -c $< -o $@
$(FC) $(FFLAGS) -c $< -o $@
.p.o:
dated and selectively building only those Looks up time of last

update and only clean:
$(PC) $(PFLAGS) $(CPPFLAGS) -c $< -o $@
$(RM) $(PACKAGE) $(OBJS)

executes minimum build $(RM) core gmon.out *~ #*#
portions of the project that were updated needed

An Introduction to Free/Open-Source Software
Makefile example
since the last build.

As software grows in scale, the process of
creating rules to support different platforms becomes more laborious. Autotools can
provide a certain degree of automation for generating rules.
228
Development Tools
11.2 The GNU Linker Ld

A linker is invoked at the end of the build
process to generate an executable file. The The GNU Linker Ld
GNU linker ld is used in FOSS develop-
Invoked at end of build process
ment. Linking involves the following pro- Link multiple object files and library or archive files
Relocate data
cedures: Tie up symbol references # ld -o a.out /usr/lib/crt1.o \

/usr/lib/crti.o hello.o -lc
Static linking
Combines all object files and libraries from build into one
1. Link multiple object files and library or program
Runs as standalone file but produces large file size
archive files. Dynamic linking

Only designates name of libraries
Dynamically links to libraries during execution
2. Relocate the data. Small file size
An Introduction to Free/Open-Source Software Copyright © 2005,2006, Mitsubishi Research Institute, Inc. All Rights Reserved. 296
3. Tie up the symbol references.
Linkage can be static or dynamic. Static linking is a linking method that combines
all object files and libraries from the build into a single file. Although the file runs as
a stand--alone file, the drawback is that it produces a large executable file. Dynamic
linking only designates the names of libraries to enable dynamic linking to libraries
during execution. The use of dynamic linking reduces the file size of the program
in its executable format. This method also has the advantage of enabling separate
management of libraries. For these reasons, dynamic linking is widely used today.
11.3 Debugger
11.3.1 Debugging
Bugs or errors inevitably arise during coding in software development. Debugging is
the process of locating and fixing bugs. The debugging process essentially involves
checking for the following items:
Debugging Tools
· Are the values of variables as expected?
Debugging
Process of fixing bugs in coding
· Does the program logic run properly? Basically check for:
Are values for variables as expected?
Is conditional branch correct?
Possible to insert code to output values at various

These items can be checked by inserting points, but labor-intensive
Use of debugging tools
code at various points of the program to Debugging tools
output the values for variables. This pro- Debuggers, profilers, tracers, etc.
cess is labor--intensive, so debugging tools

are usually used. Various types of debug- An Introduction to Free/Open-Source Software
Copyright © 2005,2006, Mitsubishi Research Institute, Inc. All Rights Reserved.
297
ging tools are used including debugger, pro-

files and tracers. Debugger are used to isolate the location of a bug, while profilers
229
Debugger
are used to check the function call efficiency or detect memory leaks. Tracers are
used to trace function calls.
11.3.2 Debugger
The major FOSS debugger is GDB, which
stands for the GNU Project Debugger. The Debuggers
GDB tool has the same features as other
GDB (The GNU Project
common debugger, such as the ability to Debugger)

CUI debugger
set a breakpoint or perform step--by--step Features: Set

breakpoints, step-by-
execution. In order to stop execution at a step execution, etc.
DDD (GNU Data
specified line of source code, a breakpoint Display Debugger)

GUI front-end for GDB
is set. The programmer then displays and and other CUI

debuggers
verifies the value of the variables. Step--

by--step execution is used to execute source An Introduction to Free/Open-Source Software
code one line at a time. Debugging with

a debugger is conducted by checking the
value of each variable while the program is temporarily stopped. This enables you
to determine if the program logic is correct.
GDB is a CUI--based program. FOSS GUI front--ends are also available such as
GNU DDD, which stands for GNU Data Display Debugger. GNU DDD can also be
used as a front--end for CUI debugger other than GDB. The slide shows a screen--
shot of GNU DDD.
11.3.3 Debugging Example

This section describes how FOSS debugging is conducted using the example of a
defect in gscanbus. gscanbus is a FOSS tool for capturing and displaying data
from a connected IEEE 1394 device.
Debugging Case Study (Part 1)
gscanbus
Tool for acquiring and
displaying data from
connected IEEE 1394
device
Problem (bug?)
Camera icon displayed
as question mark
Camera works
properly
Device type not

recognized
230
Development Tools
11.3.3.1 Identify the Problem

The first step is to examine the details of the suspected bug. In this example, a
connected IEEE 1394 camera works properly, but the device shows up as a question
mark instead of a camera icon. You can assume that the problem is due to an
inability to identify the device type.
11.3.3.2 Carefully Examine the Problem Area

Next, trace the source code to determine where the bug is hiding. Examination
of the file names contained in the gscanbus package reveals icon.h and icon.c
files. You can guess that these files contain
source code related to icon display. Debugging Example (Part 2)
Looking at the contents of the icon.h file
Dig through the source code
reveals that initIcons() and chooseIcon() File names
Icon.h and icon.c files are suspect
are functions called from outside. Based icon.h
InitIcons() and chooseIcon() functions called from
on its name, you can presume that choo- outside
ChooseIcon() is suspect; chooseIcon() function is for

initialization
seIcon() is related to the problem. initI- ChooseIcon() in icon.c file
Icon appears to be switched by rom_info>node_type
cons() is presumed to be a function for void chooseIcon(Rom_info *rom_info, GdkBitmap **xpm_node,

GdkBitmap **xpm_node_mask, char **label) {
switch(rom_info->node_type) {
case NODE_TYPE_CONF_CAM:
icon initialization. case NODE_TYPE_AVC:
*xpm_node = xpm_dvcr;
*xpm_node_mask = xpm_dvcr_mask;
*label = "AV/C Device";
By examining chooseIcon(0) from the icon.c An Introduction to Free/Open-Source Software

break;
case NODE_TYPE_SBP2:
files, it is possible to determine that the

icon used depends on rom_info->node_type.
11.3.3.3 Fix the Problem Area

Now that you have determined that there is a bug in the portion of code related to
rom_info->node_type, you can begin the debugging process. The gscanbus pack-
age contains rom_info.h and rom_info.c
files, whose names indicate that they con- Debugging Example (Part 3)
tain code related to rom_info. Using the
Debugging process
grep command, you can search the loca- Rom_info.h and rom_info.c files exist
Use grep to search location where value of node_type is set
tion where the value for node_type is set Get_node_type is suspect
Probable solution: Change code to return
in the rom_info.h and rom_info.c files. NODE_TYPE_CONF_CAM when camera you are using
(unit_sw_version=0x101) is connected
int get_node_type(Rom_info *rom_info) {
The search results tell you that get_node_type char cpu;

if (rom_info->unit_spec_id == 0xA02D) {
if (rom_info->unit_sw_version == 0x100) {
return NODE_TYPE_CONF_CAM;
} else if (rom_info->unit_sw_version == 0x10000 ||
rom_info->unit_sw_version == 0x10001) {
is likely to be the source of the problem. }

return NODE_TYPE_AVC;
} else if (rom_info->unit_spec_id == 0x609E &&
rom_info->unit_sw_version == 0x10483) {
return NODE_TYPE_SBP2;
The icon can be expected to work prop- } else {
}
resolv_guid(rom_info->guid_hi, rom_info->guid_lo, &cpu);
if (cpu) return NODE_TYPE_CPU;
return NODE_TYPE_UNKNOWN;
erly if you change the source code to re- An Introduction to Free/Open-Source Software
}
turn NODE_TYPE_CONF_CAM when the cam-

era you are using (unit_sw_version=0x101)
is connected. You can go ahead and make this change.
231
Analysis Tools
11.3.3.4 Check the Results

The last step is to build the source code
and check the results. In this example, Debugging Example (Part 4)
the icon was correctly displayed after fix-
Result
ing the code as described. However, there Icon is correctly displayed
Unknown if patch is correct method to fix problem
is no guarantee that the method you used Fix was possible because of viewable source code
Patch may be incorporated into next version by
is the correct method for fixing the prob- feeding back to community
lem. By feeding back your patch to the

community, the patch may be reviewed,
commented, and incorporated into the next
version of the software. Every piece of An Introduction to Free/Open-Source Software
feedback contributes to the growth of FOSS,

so you should make an active effort to send
feedback.
The ability to implement fixes like this one is the biggest feature of FOSS. These
fixes are possible because viewing and modifying source code are allowed with FOSS.
11.4 Analysis Tools

In addition to debugger, tools are available to analyze the status of program ex-
ecution or to analyze source code. These tools help to accelerate and improve
the quality of bug fixes. Dynamic analy-
sis tools include profilers and tracers. A Analysis Tools
profiler is used to acquire statistical infor- Analyze how program runs dynamically and/or check
mation about CPU and memory usage. A source code statically

To help bugfix, quality improvement and speed up, etc.
tracer is used to trace function calls and Profilers / memory testing tools
Tools to get statistical information on CPU and memory
system calls. Tracers
A static source code analysis tool is used to Tools to trace function calls and system calls
Source code analyzing tools

analyze source code and jump to an arbi- ctags, etags, etc.
Create tag information by reviewing source code
trary point using an editor. It is also used To jump directly to the definition of classes and functions
cflow
for visualization of source code. Tools such To show the invocation tree between functions and functions
as ctags and etags are used to generate

tag information and jump to the definition
point of a class or function. Utilities such as cflow are used to display which func-
tions call which other functions.
232
Development Tools
11.4.1 Profilers
A profiler is used to acquire (profile) and display the status of program execution at
fixed intervals. By using a profiler, it is possible to grasp hardware information such
as the processor and thread status or cache
hit ratios. A CPU profiler acquires CPU-- Profilers
related information such as CPU utiliza-
Profiling
tion rates. A memory profiler acquires in- Acquire status of program execution at fixed intervals
Show process and thread status
formation about memory usage or detects Also acquire hardware information such as cache hit
ratio
memory leaks. CPU profilers

Measure CPU utilization rates
Memory profilers
Measure memory usage, detect memory leaks
11.4.2 GNU Gprof

GNU gprof is a utility for measuring and displaying the operating status of a pro-
gram. Gprof is the leading FOSS CPU profiler. Gprof can be used to measure
processing times and the number of calls
made by each function within a program. GNU Gprof
By analyzing the measurement results, you
Utility for measuring and displaying operating
can identify functions that use up a lot of status of program

Number of calls for each function, processing time, etc.
time of memory. Finding program bottle- Using gprof

Shows bottlenecks to consider for acceleration
necks in this way is useful for accelerating Specify -pg option when compiling
Execute program normally
the overall program. The basic procedure # gprof executable-file gmon.out
Sample output
for using gprof is as follows: func1 takes up zero time
func2 has room for acceleration
% cumulative self self total

time seconds seconds calls ms/call ms/call name
100.00 0.40 0.40 80 5.00 5.00 func2
1. Compile a program using gcc with the 0.00 0.40 0.00 3 0.00 133.33 func1
An Introduction to Free/Open-Source Software 305
“-pg” option if you want to use gprof.

2. Execute the program normally.
3. Execute the command below. # gprof executable-file gmon.out
The slide at right shows a sample output from gprof. The results show that execution
of func1 took zero time, while execution of func2 took nearly all of the time. This
indicates that accelerating func1 will have barely any effect on accelerating the
program. Accelerating func2 will help to accelerate the overall program.
233
Analysis Tools
11.4.3 Memory Testing

This section examines two memory profil-
ers, MemProf and Memwatch. MemProf is a Memory Testing
GUI memory profiler that can be used to
MemProf
profile memory usage or test for memory Profiler for memory

usage
leaks. The slide at right shows a screen-- Test for memory leaks
MEMWATCH
shot of MemProf. CUI memory testing
tool for C
Memwatch is a CUI memory testing tool Detection of memory

leaks, data corruption,
for the C language that can be used to etc.
detect memory leaks and data corruption.

Use of Memwatch needs to be specified in An Introduction to Free/Open-Source Software
source code and during compiling. Since

Memwatch is tailored for the C language, it
can show which portion of source code is causing a memory leak.
11.4.4 Tracers
A tracer tool is used to trace function calls and system calls. Several FOSS tracers
are available for different tracing purposes.
Tracers
Traces function calls and system calls
CTrace
Traces function calls
Ltrace
Traces function calls for shared libraries
Strace for GNU/Linux and ktrace for *BSD

Traces system calls
__libc_start_main(0x080664e0, 1, 0xbffff654, 0x08106ab0, 0x08106af8 <unfinished ...>

setlocale(6, "") = "ja_JP.eucJP"
bindtextdomain("sylpheed", "/usr/local/share/locale") = "/usr/local/share/locale"
bind_textdomain_codeset(0x08106c02, 0x08106ba0, 0xbffff608, 0x08106aca, 0x40608968) = 0x08142870
textdomain("sylpheed") = "sylpheed"
g_get_current_dir(0x08106c02, 0x08142870, 0xbffff608, 0x08106aca, 0x40608968 <unfinished ...>
malloc(4097) = 0x08142890
・・・
Sample output from ltrace
11.4.4.1 CTrace
CTrace is a tracer for function calls and is used for programs written in C. The ctrace
command embeds tracing text into C language programs. When a modified program
is compiled and executed, the trace status is output at execution so that you can
check the operation of the program. To check shell script operation, designate the
-x option when executing a shell script.
234
Development Tools
11.4.4.2 Ltrace
Ltrace is used to trace calls for shared library functions. The slide shows a sample
output from ltrace. The ltrace output displays the call status of shared libraries
as function--name (argument) = returned--value. Unlike CTrace, programs do not
need to be recompiled when using ltrace.
11.4.4.3 Strace, Ktrace

Strace and ktrace are used to trace system calls. Strace comes with GNU/Linux,
while ktrace comes with BSD. Truss is a tracer for Solaris.
11.5 Source Code Management

Source code management tools are used to manage source code, configuration files
and various documents, as well as their respective change histories. Team--based
software development must be conducted
by allowing each member to grasp the con- Source Code Management
tents of source code added by other mem-
Manages source code itself, the changing history
bers, or else development becomes confus- and so on

Essential tool for team development
ing. In some instances, you may wish to To make sure when, who, where and how modified?
Reverting back to older revision and/or making branch
roll back to an older version when a prob- versions are possible
Inevitability of source code management tool
lem occurs, or to create a branch version RCS, CVS, subversions and other similar tools were
developed in association with changes of development
to test new features. Various source code styles from independent development to team and
distributed development
management tools have been developed to

address the need for these features. An Introduction to Free/Open-Source Software
Source code management tools have evolved

as development styles have changed. Basic
version control was adequate when software development was still conducted by one
individual. The shift to team--based development led to a need for exclusive file
access, leading to the development of the Revision Control System (RCS) tool. As
development teams grew in scale, a bottleneck consisted in developers waiting for
file locks to be released. To resolve the issue tools were developed allowing multiple
team members to concurrently edit the same file. Increasing use of distributed de-
velopment over networks was also a factor in creating demand for features beyond
those provided by RCS. Tools such as Concurrent Versions System (CVS) and Sub-
version were developed to address the demand for these features. More recently, the
growth in development teams has shown centralized repositories to be a bottleneck
and several distributed version control tools such as git and ????? have appeared.
235
Source Code Management
11.5.1 Diff and Patch

Version control is the most basic feature
of source code management tools such as Diff, Patch
RCS, CVS and Subversion. Under ver- Patchfile (shown at right)
sion control, snapshots need to be saved Shows differences between files
*** hello.c 2005-06-17 17:46:46.000000000 +0900

Diff and patch
for each version of software. Changes are diff
--- nice.c
***************
*** 3,5 ****
!
int main(void){
2005-06-17 17:47:04.000000000 +0900
printf("Hello World!\n");
return 0;
--- 3,5 ----
Tool to generate differences
typically to only a few lines in a file and patch

!
int main(void){
printf("Nice to meet you!\n");
return 0;
Tool for applying differences to create revised file
hence saving the entire file results in much Basic features of RCS, CVS and Subversion
duplication. Consequently, only the dif- Used by someone other than source code administrator
to create bug fixes or add features
Redundant to send entire modified file

ferences between old and new versions are Send only differences to administrator
Practice dates back to when transmission speeds were
normally saved. slow, making it necessary to reduce data volume

Diff utilities are used to generate differ-

ences between files. The patch tool is used
to generate a new version by patching the differences to old versions of files. Source
code management tools also use diff and patch features to generate differences, which
are output to a patch--file. The slide shows a sample patch--file. The sample patch--
file illustrates how it is comprised of information about old and new versions of files
and their differences.
Many FOSS development projects provide open (read) access to the source code
repository managed using CVS to any individual. However, only core members have
permission to write to the repository. If a developer without write privileges writes
a bug fix or adds features to a program, that person can send a patch generated
using the diff command. Sending just the patch makes it easier to understand the
changes that were made. It also reduces the size of the file being sent. This practice
dates back to when transmission speeds were slow, making it necessary to keep file
sizes as small as possible.
236
Development Tools
11.5.2 Version Control (SCCS, RCS, CVS and Subversion)

The major source code management tools are SCCS, RCS, CVS and Subversion.
CVS is widely used for FOSS development, but an increasing number of projects
today use Subversion.
Version Control (SCCS, RCS, CVS,
Subversion)
SCCS and RCS Commands in CVS and

Version control for single Subversion
files checkout
CVS Creates working copies from

repository
Creates working copies
on client based on commit
contents of server Saves to repository
(repository) update
Enables concurrent Updates working copies
editing of same file by
add/delete
multiple persons
Adds and deletes files
Subversion diff
Addresses downsides of Shows differences between files
CVS (inability to move or
status
delete directories, etc.)
Shows status of files
11.5.2.1 SCCS and RCS

Source Code Control System (SCCS) and RCS are version control systems for single
files. These tools are capable of managing version and change histories. To edit a
file the developer locks that file and thereby prevents other developers from editing
the same file. As soon as a change is submitted the lock is released.
11.5.2.2 CVS
Where RCS enables multiple users to share the same file stored on one computer,
CVS uses a server architecture to manage a repository. Under this arrangement,
users copy the contents of the repository to individual clients. This enables multiple
individuals to concurrently edit copies of the same file. When a change is made to
the original file, CVS automatically merges the changes from copied files. If changes
are made to the same portion of the original file, the developer has to decide how
to merge the overlapping changes.
11.5.2.3 Subversion
Subversion shares the same basic features and operating method as CVS, but with
enhancements to address the downsides of CVS. Specifically, Subversion includes
the ability to move and delete directories and to track these changes as part of the
versions. These features are missing in CVS. Subversion is upwardly compatible
with CVS.
237
Other Tools
11.5.2.4 Commands in CVS and Subversion

This section describes the basic commands used in CVS and Subversion. The check-
out command is initially used by the developer to create working copies on the client
from the repository on the server. The user edits these working copies.
After finishing a round of editing, the commit command is used to save the contents
of working copies to the repository. If the repository has been updated in the
meantime, the update command is used to refresh the working copies on the client
so that they remain up--to--date.
The add and delete commands are used to add and delete files to the repository.
These changes do not affect the repository until the commit command is used. The
diff command is used to show differences between specified file versions. The
status command acquires information about the status of files. This information
shows whether files are the latest versions or whether they have been updated on
the server or clients.
11.6 Other Tools

The final part of this chapter examines other relevant tools that are effective in
FOSS development. These tools include compatibility tools that absorb the differ-
ences between platforms and localization frameworks to add language support to
software. Documentation tools, integrated development environments (IDEs) and
bug management systems are also presented. The tools described in the following
sections represent just a small selection of the FOSS tools that are available. Many
other tools have been developed to cover various applications.
238
Development Tools
11.6.1 Maintaining Compatibility

For FOSS developers, one of the positive aspects of FOSS development is to see your
software widely used by others. However, differences between platforms need to be
absorbed in order to run one program on
many computers. The major factors that Maintaining Compatibility
lead to platform differences are as follows:
Differences in platforms
Differences in operating systems
1. Differences in operating systems are a GNU/Linux, *BSD, Unix, Windows, etc.
Differences in libraries
OpenGL/Mesa, Xaw, Motif/lesstif, etc.
very significant factor, such as the dif- Differences in versions
Specifications can change due to version upgrades
ferences between GNU/Linux, *BSD, Differences in paths
Unix and Windows. Need arrangement for absorbing these

differences
Labor-intensive to implement manually
Difficult to support platforms not possessed by
2. Next is the difference between libraries. developers
Libraries may be compatible in features An Introduction to Free/Open-Source Software

311
and specifications but exist in differ-

ent implementations. Examples include OpenGL and Mesa, or Xaw and Mo-
tif/LessTif.
3. The specification for a library can change due to a version upgrade, leading to
incompatibilities with the previous version of the library.
4. Differences in the library path can occur, compared with the computer envi-
ronment used for development. For example, a library can be located in the
/usr/local/lib directory or in /usr/lib.
Developers must consider these differences when developing software. However,

ensuring compatibility with many platforms is a complex process and difficult to
implement manually. There is also a limit to the number of platforms that developers
and development teams can keep on hand. This makes it difficult to ensure support
for platforms not possessed by developers. The tools described in the next section
can be used to largely automate the task of maintaining compatibility.
239
Other Tools
11.6.2 GNU Autotools

Obtaining source code does not guarantee that a program can be built under your
own environment and executed. To compile and execute the same program on
different platforms (OS or environment),
it is necessary to use a tool for adjusting GNU Autotools
configurations to enable execution. GNU
Need more than just source code
Autotools was developed to address these Need tools to compile and execute same program on
different platforms (OS or environment)
needs by helping to improve the portability Improve portability and maintainability
Tools such as autoconf, automake, etc.

and maintainability of software. Autoconf: Used to generate configure scripts
Automake: Used to generate makefiles
A configure script can be used to gather Minor format differences depending on version
information about an environment and au- of Autotools used

Contradicts the very purpose of Autotools?
tomatically configure build parameters to

that environment. Configure scripts are An Introduction to Free/Open-Source Software
used for many FOSS projects to improve

the portability of that software. The actu-
al configure script is written as a shell script under the assumption that platforms
share a minimum scripting environment. The configure script is typically very com-
plex due to the need to test a variety of conditions. Writing a configure script
manually is very labor--intensive.
GNU Autotools is a tool--chain comprising of Autoconf and Automake. Autoconf
is used to generate configure scripts, while Automake is used to generate makefiles.
Although Autotools improves the portability of software, it also has some issues. The
format of configuration files differs slightly depending on the version of Autotools
used. If the version of Autotools is different from the one used by the original
developer, some configuration files must be rewritten. Consequently, some of the
portability that is the purpose of Autotools is lost.
240
Development Tools
11.6.3 Localization
In most parts of the world, English increasingly serves as the universal language of
the FOSS community. However, there are many developers and users who lack En-
glish skills. Furthermore, many users de-
sire software in their own native language, Localization
even if they do have good English--language
English is the universal language of FOSS
skills. Developers should make an effort to development

Many developers and users lack English skills
prepare versions of software in languages Desire for different language versions so that many
others can use software
other than just English and the developer’s Localization

Enables display of character strings such as menus
own native language, so that many people and dialogs in different languages
Developers do not need to be versed in each language
can use the software. Localization is criti- Translators do not need to understand source code
Localization tools do not support
cal for this purpose, in order to enable the internationalization

Multilingual handling, line breaks, etc.
display of menus, dialogs and other char- See I18n, M17n and L10n

acter strings in various languages.

Localization centers on the work of trans-
lators in various countries, rather than centering on the original developers. This
is because it is impossible for the original developer to translate into all languages.
Tools that support localization must satisfy the following two conditions:
· developers do not need to be versed in each language
· translators do not need to understand source code
Localization tools can support the display of menus and other elements in different
languages. However, these tools are not equipped to implement internationalization
such as multilingual handling and line breaks. Localization, internationalization
and multilingualization are discussed in detail in Section 10.5.3: I18n, M17n and
L10n.
241
Other Tools
11.6.4 GNU Gettext

GNU gettext is frequently used for localization of FOSS. gettext enables local-
ization without major changes to existing source code. Localization with gettext
is performed using the following steps:
GNU gettext
1. Prepare a message catalog. The mes-
sage catalog consists of a combination Implements localization without major changes to
existing source code
of labels (msgid) and character strings Prepare a message catalog
Surround the internationalized character string with N_()
Ex. Change char *str = "Hi"; to char *str = N_("Hi");
(msgstr). Surround variables that call on the string with _()
Ex. Change printf("%s\n", str); to printf("% s\n", _(str));
Example of message catalog
2. Surround the internationalized charac- Replaces Hi (msgid) with Guten Tag (msgstr)
msgid "Hi"
ter string with N_(). msgstr "Guten Tag"
msgid "Add"
msgstr "Hinzufuegen"
Ex. change char *str = "Guten Tag"; msgid "Edit"

msgstr "E ditieren"
to char *str = N_("Guten Tag");. An Introduction to Free/Open-Source Software

314
3. Surround variables that call on the character string with _().

Ex. change printf("%s\n", str); to printf("%s\n", _(str));.
In the example shown above, “Guten Tag” (msgid) is replaced with “Welcome” (ms-
gstr). To support many languages, a message catalog for each target language must
be prepared.
11.6.5 Documentation
Many FOSS developers place a lower priority on creating documents such as manuals
and specifications, compared with the priority they place on software development.
There are few FOSS projects that prepare
adequate documentation. The problem is Documentation
so widespread that lack of documentation
Importance of documentation
is cited as one reason for hesitation in de- Expand user base
User manual
ploying FOSS. This section stresses the im- Expand developer base
Helpful for hacking
portance of documentation. Above all, documentation helps the original developer
Tendency to forget the purpose of old code
Documentation is critical for users and oth- Writing documents perceived as bothersome
er developers. It is also important for the Documentation tools

Automatically generate documents from source code
original developers themselves. Preparing Can also graph class relationships, etc.
Not designed to identify purpose of program
user’s manuals helps to increase the user An Introduction to Free/Open-Source Software

base, which leads to identification of bugs.

Preparing specifications and other docu-
mentation for developers is helpful to developers who use FOSS. Providing this
type of documentation also increases the likelihood that developers will write bug
fixes or add features by hacking FOSS source code.
242
Development Tools
Documentation also benefits the original developer. If you have ever been involved in
software development, you know that sometimes it is possible to forget the purpose of
source code written a week or a month ago. Documentation is effective in preventing
this type of situation from happening.
Creating documents is time--consuming, but documentation tools can be used to
effectively streamline the process. Documentation tools automatically generate doc-
uments from source code. These tools can shape the comment style within source
code and graph class relationships. However, documentation tools do not analyze
the contents of source code to identify the purpose of the program. If you wish to
reflect the purpose of the program in documents, then you must mark portions of
the source code with comments.
11.6.6 Doxygen, Javadoc, Doc++

The three leading documentation tools are Doxygen, Javadoc and Doc++. Doxygen
and Doc++ support multiple languages such as Java, C, C++ and PHP. Users can
select from HTML or LaTeX as the out-
put format. Javadoc only supports Java, Doxygen, Javadoc, Doc++
but comes standard with JDK. This means
Doxygen/Doc++
that you can use Javadoc in all your Java Supports Java, C, C++,
PHP, etc.
projects. All tools extract specially for- Output in HTML or LaTeX

formats
matted documentation from source code JavaDoc

Comes standard with JDK
files and use the context in which this doc-

umentation is found (e.g. class name of a
class being declared) to generate documen-
tation for the software. An Introduction to Free/Open-Source Software
Sample output from Doxygen
243
Other Tools
11.6.7 Integrated Development Environments

Despite the multitude of Unix, GNU/Linux and GNU programming tools that
are available, many employ a CUI. Although CUI tools are extremely convenient
for developers who are familiar with them,
they can be difficult to master. CUI tools Integrated Development
Environments
make it difficult for Windows developers
Unix and GNU programming centers on
to get involved in Unix software develop- command line tools

Convenience of many tools, but tools are difficult to
ment, since Windows developers are famil- master
Difficult to program outside of IDE framework
iar with GUI development environments. Demand for GUI-based IDEs as developer base grows
Simplifies migration from Windows development

environments
GUI integrated development environments Leading IDEs
(IDEs) are available for Windows develop- Eclipse with multi-language support
Anjuta for GNOME applications
ment and are the primary choice for de- KDevelop for KDE applications
velopment on that platform. IDEs provide An Introduction to Free/Open-Source Software

an integrated interface for various features

and are extremely easy to use within the
features offered by the IDE. The downside is that it is difficult to use features not
available within the IDE.
Both CUI and GUI development environments have their respective advantages and
drawbacks. Demand for GUI IDEs for Unix and GNU/Linux environments has
emerged as the FOSS developer base has grown. Several IDE projects are being
developed today. The emergence of FOSS IDEs simplifies the process of migrating
to Unix and GNU/Linux development for developers who are familiar with Windows
development. Leading IDEs include Eclipse with multi--language support, as well
as Anjuta for GNOME applications and KDevelop for KDE applications.
244
Development Tools
11.6.8 Eclipse
The most famous FOSS IDE is Eclipse. Eclipse was written in Java and runs on a
wide range of operating systems that support Java. The advantages of Eclipse are
its high extensibility and plug--in architec-
ture to strengthen various features. Mod- Eclipse
ules and plug--ins are available for multi--
IDE written in Java
language support including Java, C, C++, Runs on variety of operating systems
PHP, Ruby and COBOL. The plug--in ar- High extensibility

Billed as universal tool platform
chitecture of Eclipse in some ways makes Plug-in architecture to strengthen various features
Plug-ins for Java, C, C++, PHP, Ruby and COBOL
up for the disadvantages of IDEs. Due to History of Eclipse

IBM Visual Age released as FOSS
its high extensibility, Eclipse is billed as a IBM sells Eclipse-based IBM Rational Software
Development Platform
“universal tool platform” rather than an

IDE. An Introduction to Free/Open-Source Software
Eclipse was originally sold by IBM under

the name Visual Age, before it was re-
leased as FOSS in 2001. IBM currently sells the IBM Rational Software Devel-
opment Platform, which is based on Eclipse. IBM’s rationale for releasing Eclipse
was to increase the number of developers that can use Eclipse. Since Eclipse devel-
opers can also use IBM Rational Software Development Platform, IBM is banking
that more developers will buy its software.
11.6.9 Bug Reporting Tools

For development of smaller scale software, e--mail and spreadsheets are adequate
tools for bug reporting and management of correction histories. As software grows
in scale, the number of bugs also increas-
es so that only some bugs get corrected. Bug Reporting Tools
The involvement of multiple developers al- Also called bug tracking systems
so makes it necessary to grasp the work Dedicated database for bug tracking
Well-known tools: Bugzilla, Debian bug tracking system (BTS),
done by each person. E--mail and spread- GNU GNATS
Centralized management of bugs
sheets become inadequate for managing bugs, As software grows in scale, management tools such as e-mail
and spreadsheets become inadequate for grasping overall
picture
resulting in the need for a centralized sys- Stores information such as bug reporter, reproduction method,
bug correction assignee, correction history, correction method,
tem for managing bugs. This type of sys- degree of importance, test status, etc.
Bug life cycle

tem is called a bug tracking system or bug (1) bug report, (2) assignment of person to correct bug, (3)
correction of bug, (4) testing and (5) close of bug report
reporting tool. Bugs can sometimes recur after bug correction or during testing

A bug reporting tool is a dedicated database

for bug tracking. Major bug reporting tools
include Bugzilla, the Debian bug tracking system (BTS), and GNU GNATS. These
databases track the life cycle of each bug by storing various information about
245
Chapter Review
bugs. This information includes the bug reporter, reproduction method and per-
son assigned to correct the bug. Also tracked are the correction history, correction
method, degree of importance and test status.
A bug life cycle refers to the sequence of events from bug identification until the bug
report is closed. Typically, the life cycle involves the following sequence of events:
1. bug report,
2. assignment of person to correct bug,
3. correction of bug,
4. testing to verify correction of bug, and
5. close of bug report.
In some cases, bugs can recur after they are corrected, due to fixing a different part
of the software or when testing reveals that the bug correction was inadequate.
11.6.10 Bugzilla
Bugzilla is a bug reporting tool that was developed by Mozilla.org for the Mozilla
browser. The software is known for its powerful bug tracking and search features. In
addition to being used internally by Mozil-
la.org, Bugzilla is used by other large--scale Bugzilla
projects such as XFree86, Apache, Samba,
Developed by
and GNOME. Mozilla.org to track

bugs for Mozilla
browser
Powerful bug tracking
and search features
Used for projects such

as XFree86, Apache,
Samba, GNOME, etc.
11.7 Chapter Review

· What are the kinds of tools used in software development?
· Explain the typical stages in the build of a program.
· How do developers manage complex builds?
246
Development Tools
· Explain the purpose of the programs gcc and ld.
· What are the advantages and disadvantages of static and dynamic linking?
· How can a debugger help in fixing a problem with a software package?
· What is the purpose of a profiler?
· What do the tools diff and patch do?
· What essential feature does CVS have that RCS does not have?
· What essential feature does Subversion have that CVS does not have?
· Explain the different actions a developer commonly performs on the repository

with CVS or Subversion.
· What is the purpose of the autotools?
· Explain which steps are taken to when localizing software with gettext.
· What are the main advantage and the main disadvantage of GUI IDEs compared
to CUI tools?
· Explain the bug life cycle. What are its main events?
· What is the purpose of bug reporting tools?
247

11 Development Tools: 11.1 Program Builds

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

11 Development Tools: 11.1 Program Builds

Uploaded by

Copyright:

Available Formats

Development Tools

development. The developers then release tool for themselves

Plenty of tools for

these tools as FOSS. Since distributed de- distributed development

velopment over the Internet is the prima- Internet

GUI-based tools are

ment tools for this purpose are particularly

ment tools were CUI--based, but the num-

11.1 Program Builds

compiler, which converts the source code Compile

Source code -> object code

into an object code written in machine lan- Link

Set of object code -> executable code

libraries using a linker, in order to create gcc, make, ld

an executable program. In FOSS develop-

The complexity of the build process in-

C++ compiler g++

C language. The features were later ex- Fortran compiler g77

Java compiler gcj

tended to include other compilers and li- Features

Can also be used as cross-compiler

guages beyond C. GCC now includes the C An Introduction to Free/Open-Source Software

compiler gcc, the C++ compiler g++, the

mizing the tasks required to update builds. and processing method

This feature is accomplished by compar- installation, etc.) are

dated and selectively building only those Looks up time of last

$(RM) $(PACKAGE) $(OBJS)

portions of the project that were updated needed

since the last build.

11.2 The GNU Linker Ld

cedures: Tie up symbol references # ld -o a.out /usr/lib/crt1.o \

1. Link multiple object files and library or program

Runs as standalone file but produces large file size

archive files. Dynamic linking

Dynamically links to libraries during execution

2. Relocate the data. Small file size

3. Tie up the symbol references.

· Does the program logic run properly? Basically check for:

Are values for variables as expected?

Is conditional branch correct?

Possible to insert code to output values at various

Use of debugging tools

code at various points of the program to Debugging tools

cess is labor--intensive, so debugging tools

ging tools are used including debugger, pro-

common debugger, such as the ability to Debugger)

set a breakpoint or perform step--by--step Features: Set

execution. In order to stop execution at a step execution, etc.

DDD (GNU Data

specified line of source code, a breakpoint Display Debugger)

is set. The programmer then displays and and other CUI

verifies the value of the variables. Step--

code one line at a time. Debugging with

11.3.3 Debugging Example

Device type not

11.3.3.1 Identify the Problem

11.3.3.2 Carefully Examine the Problem Area

reveals that initIcons() and chooseIcon() File names

Icon.h and icon.c files are suspect

are functions called from outside. Based icon.h

InitIcons() and chooseIcon() functions called from

on its name, you can presume that choo- outside