1.4 System Building

• Involves taking all system components and combining them into a single executable system
• Different systems are built from different component combinations
• May take several days for large systems if all components are compiled and linked at the same time

1.4.0.0 System building problems  

• Do the build instructions include all required components?
  • When there are many hundreds of components making up a system, it is easy to miss one out. This should normally be detected by the linker

• Is the appropriate component version specified?
  • A more significant problem. A system built with the wrong version may work initially but fail after delivery

1.4.0.0 System building problems (cont.)  

• Are all data files available?
  • The build should not rely on 'standard' data files. Standards vary from place to place

• Are data file references within components correct?
  • Embedding absolute names in code almost always causes problems as naming conventions differ from place to place

1.4.0.0 System building problems (cont.)  

• Is the system being built for the right platform?
  • Sometimes must build for a specific OS version or hardware configuration

• Is the right version of the compiler and other software tools specified?
  • Different compiler versions may actually generate different code and the compiled component will exhibit different behaviour

1.4.0.0 System representation  

• Systems are normally represented for building by specifying the file name to be processed by building tools. Dependencies between these are described to the building tools
• Mistakes can be made as users lose track of which objects are stored in which files
• A system modelling language addresses this problem by using a logical rather than a physical system representation

1.4.0.0 System building with make  

• Most widely used build tool on the Unix system is make. Comparable tools are available on other systems
• User specifies component dependencies and make automatically forces recompilation of required files when it detects that the source code has been changed after the object code was created

1.4.0.0 Sample component dependencies  

1.4.0.0 Sample Makefile  

include ../config.mk.$(OSTYPE) # #  What is the name of the program you want to create? # TARGET=$(ALIB) # #  List the object code files to be produced by compilation. # OBJS=algae.o algaeapp.o animatpn.o animatw.o \      astream.o compound.o defaults.o fontsel.o \      nodes.o stdiopn.o stdiow.o timer.o \      tracepn.o tracew.o visible.o # #  The following is "boilerplate" to set up the standard compilation #  commands: # .SUFFIXES: .SUFFIXES: .d .o .h .c .cc .C .cpp

RECORDDEP=-MD .c.o: ; $(CC) $(CFLAGS) $(RECORDDEP) -c $*.c .cc.o: ; $(CPP) $(CPPFLAGS) $(RECORDDEP) -c $*.cc .C.o: ; $(CPP) $(CPPFLAGS) $(RECORDDEP) -c $*.C .cpp.o: ; $(CPP) $(CPPFLAGS) $(RECORDDEP) -c $*.cpp

• These are example of production rules.
• E.g., to produce a file foo.o when a file foo.c is available,
  • invoke the C compiler ($(CC))
  • . . . with options $(CFLAGS) -Md -c foo.c
    • In this makefile, $CC, $CPP, $(CFLAGS), etc., are defined in a separate configuration file, config.mk

# # Targets: # all: $(TARGET) referencemanual.ps $(TARGET): $(OBJS)         rm -f $(TARGET)         ar cr $(TARGET) $(OBJS)         $(RANLIB) $(TARGET)         chmod 644 $(TARGET)

• General form:

  target: files it depends on    commands to make it

• The commands may be omitted if they are covered by a production rule.

clean:         -rm -f $(TARGET) $(OBJS) $(DEPENDENCIES) referencemanual.ps: referencemanual.dvi bstsess.eps         dvips referencemanual referencemanual.dvi: referencemanual.tex $(PROGRAMS)         latex referencemanual

• More dependencies and rules.
• Note that make is perfectly capable of dealing with activities besides compilation of source code.

algae.o: algae.cpp $(APATH)/algae/algae.h \  $(ACONFIG)/algae/config.h \  $(ACONFIG)/algae/string.h \  $(APATH)/algae/astream.h \  $(VPATH)/v/v_defs.h \  $(VPATH)/v/vcolor.h $(APATH)/algae/visible.h \  $(APATH)/algae/compound.h $(APATH)/algae/algaeapp.h \  $(APATH)/algae/points.h $(VPATH)/v/vapp.h \  $(VPATH)/v/vbaseitm.h $(VPATH)/v/vfont.h \  $(VPATH)/v/vawinfo.h $(VPATH)/v/vmenu.h \  $(VPATH)/v/vpane.h $(VPATH)/v/vtimer.h \  $(VPATH)/v/vnotice.h $(VPATH)/v/vmodald.h \  $(VPATH)/v/vdialog.h $(VPATH)/v/vbasewin.h \  $(VPATH)/v/vcmdprnt.h $(VPATH)/v/vcmd.h \  $(VPATH)/v/vreply.h $(VPATH)/v/vynreply.h algaeapp.o: algaeapp.cpp $(APATH)/algae/algaeapp.h \  $(ACONFIG)/algae/config.h \  $(ACONFIG)/algae/string.h \  $(APATH)/algae/points.h $(VPATH)/v/vapp.h \  $(VPATH)/v/vbaseitm.h $(VPATH)/v/v_defs.h \  $(VPATH)/v/vfont.h \  $(VPATH)/v/vawinfo.h $(VPATH)/v/vmenu.h \  $(VPATH)/v/vpane.h $(VPATH)/v/vtimer.h \  $(APATH)/algae/animatpn.h $(VPATH)/v/vcanvas.h \  $(VPATH)/v/vcpdc.h $(VPATH)/v/vwindc.h \  $(VPATH)/v/vdc.h $(VPATH)/v/vpen.h \  $(VPATH)/v/vcolor.h $(VPATH)/v/vbrush.h \  $(VPATH)/v/vprinter.h $(VPATH)/v/vwinprtr.h \  $(VPATH)/v/vmodald.h $(VPATH)/v/vdialog.h \  $(VPATH)/v/vbasewin.h $(VPATH)/v/vcmdprnt.h \  $(VPATH)/v/vcmd.h $(VPATH)/v/vmemdc.h \  $(APATH)/algae/animatw.h $(APATH)/algae/timer.h \  $(VPATH)/v/vcmdwin.h $(VPATH)/v/vwindow.h \  $(VPATH)/v/vstatusp.h $(VPATH)/v/vcmdpane.h \  $(APATH)/algae/defaults.h $(APATH)/algae/stdiow.h \  $(APATH)/algae/stdiopn.h $(VPATH)/v/vtextcnv.h \  $(APATH)/algae/tracew.h

• These dependency lists can be generated automatically by the compiler
• The compilation commands are covered in the general production rules.

1.4.0.0 make problems  

• Based on a physical rather than a logical model of dependencies
• Dependency specifications (Makefiles) quickly become large, complex, hard to understand and expensive to maintain
• make uses a simple model of change based on file update times. Source code changes need not require re-compilation.

1.4.0.0 make problems  

• make does not (easily) allow versions of tools such as the compiler to be specified
• Not tightly linked to version management tools such as RCS. Manual intervention is usually needed to check out source code from a version management system for building

1.4.0.0 Integrated CM databases  

• Integrate information about the configuration with the entities which are themselves being managed.
• Generally based on ERA semantic model where entities participate in relationships and have associated attributes.
• Include process information e.g.. an entity attribute may have a value which is a process description showing how that entity was created.

1.4.0.0 CM support with an integrated DB  

• CM tools may be implemented using database query and browsing facilities
• Using process information, other tools such as editors/compilers etc. can be integrated and can automate version creation
• Information dissemination re versions and changes can be incorporated in the process information

1.4.0.0 Database-oriented CM tools  

• Rely on a powerful semantic or object-oriented database
• Store both process and product information
• Provide an integrated set of tools for configuration management
• Integrated with other tools through the database
• Graphical user interface
• Still research prototypes

1.4.0.0 Summary  

• CM is the management of system change to software products
• Effective CM is essential in large software projects
• CM activities include CM planning, change management, system building, and version and release management
• Version and change control can be supported by tools like RCS.

1.4.0.0 Summary  

• System releases should be phased with releases fixing problems interleaved with releases offering new functionality
• System building involves assembling components into a system. It is always supported by system building tools such as make