- Consider this monolithic program Monolithic.c
- Placing the code into one source file has a number of shortcomings:
- It doesn't reflect the modularity of the design.
There is no clear separation of the ADTs from each other and the main program. - There is no information hiding.
The main program contains details of the PersonType representation which it doesn't need to know. - It doesn't scale. Storing a large program as a single file produces large files that are hard to navigate. Every time a change is made to one part, the whole program has to be recompiled.
- It doesn't reflect the modularity of the design.
- The mechanisms that enable us to reflect modularity in our code are interface and implementation and separate compilation.
- A module's interface is a description of the data and functions that are visible to code external to the module. These descriptions are usually just the type signatures of the externally visible data and functions.
- A module's implementation comprises the data structures and code that make the module work.
- Separating the interface from the implementation is the way we reflect abstraction.
- When we use a module, we need to know only what effects accessing the data and routines in its interface will have and we can ignore the details of how the module is implemented.
- The code above can be split into 4 files as follows:
- CString.h - defines the CString type
- Person.h - defines the PersonType type
- PrettyPrint.h - defines the PRETTY_PRINT macro
- Person.c - implements the person manipulation
- Modular.c - main program
- This separates the interface of the ADT from the implementation. The "declare before main, define afterwards" style of programming makes the split easy to do.
- The files can all be compiled together
- gcc -Wall -o Modular.out Modular.c Person.c
- Separating the interface from the implementation means compiling multiple small files.
- Some files need not be recompiled when changes are made.
- The compiler has some options that support multi-file program development.
- The UNIX commands to compile and link separately are
- gcc -Wall -c Source.c to compile
- gcc -Wall -o Executable Object1.o Object2.o ... to link
- For the example above ... these are the file dependencies
- Large programs broken up may use many object and library files.
- Changing a source file means updating the objects, libraries and executables that depend on the source file.
- Build control is the process of determining which versions of code are required to build a product. There are many different build control systems, including make, ant, gradle, maven, etc.
- The UNIX make utility is an effective build control system for non-complex builds. It keeps track of such dependencies, and rebuilds only the necessary files.
- To determine which source files are part of the target to be built, and which
tools to use to build the target, make uses a Makefile.
- A simple Makefile for the modular program
- Lines starting with a # are comments
- A Makefile is a sequence of rules in the form
target: dependencies action - Targets are file names (or phony targets - see below)
- Actions are just standard UNIX commands that are fed to a shell. Note that an action must be preceded by a tab character; this is a historical artifact that no one has bothered to fix.
- If a dependency does not have a target entry, it is expected to exist as a result of external activity, e.g., editing.
- Makefiles are processed from the top down, trying to create a target.
By default the first target is used, but any target can be specified on the command line.
make(Target) { foreach Dependency do { if (IsATarget(Dependency)) { make(Dependency) } } if (!FileExists(Target) || AnyNewer(Dependencies,Target)) { DoActions(Target) } } - Use make to run the Makefile (or make -f makefile_name for a "makefile" with some other name).
- By default the first target is built. You can specify a target name on the command line.
- Make variables can hold values like environment variables.
Common variables are ...
CC = gcc CFLAGS = -O2 -Wall LD = $(CC)
- make automatically sets the value of certain variables like $@.
Variables of this ilk include:
- $@ The file name of the target of the rule.
- $< The name of the first dependency.
- $^ The names of all the dependencies with spaces between them.
- $? The list of dependencies that are out of date.
- make has
implicit rules that it applies by default, specified in
/usr/share/lib/make/make.rules.
For example, make knows that to get from a .c file to a .o
file, it must run the compiler specified in CCwith the -c flag.
- Makefile using defaults
- In addition to targets that build programs, make can be made to perform other
housekeeping by specifying targets that are not files.
For example, a common target is
clean: rm -f *.o *.bak *~which causes make to delete object files and any backup files (*.bak and *~) created by other programs such as editors. Another common target is all that lists all the file targets to build. To avoid confusion, non-file targets should be listed as .PHONY. - A more realistic Makefile for the example
- .o files can be combined into libraries using the ar utility.
- Library files are given a .a extension.
- The object files can be used by the compiler by specifying the location of the library file with the -L flag, and giving the library file name.
- Example
prompt> gcc -c *.c prompt> ar -rv libmystuff.a *.o prompt> pwd /home/geoff/c prompt> gcc -Wall -o MyMain.out MyMain.c -L/home/geoff/c -lmystuff