- 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 we make a change to one part, we are forced to recompile the whole program.
- 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.
- We can split the code above 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 files can all be compiled together
- gcc -o Modular Modular.c Person.c
- The "declare before main, define afterwards" style of programming makes the split easy to do later. Compare these two ...
- Separating the interface from the implementation means compiling multiple small files, and some code is compiled multiple times.
- 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 -c Source.c to compile
- gcc -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 recreates only the dependant 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 file called Makefile in the current
directory.
- 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 actionNote that action must be preceded by a tab character; this is a historical artifact that no one has bothered to fix. - Actions are just standard UNIX commands that are fed to a shell
- 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) } } - Make variables can hold values like environment variables.
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 C compiler with
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 necessarily programs. 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. - makedepend or mkdep
- Examines each of the source files in its command line and looks for #include directives.
- Generates a list of source files that are needed by the compiler to produce the resulting target.
- Result is placed in .depend (FreeBSD) or appended to makefile (Linux)
- 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 MyMain.c -L/home/geoff/c -lmystuff -o MyMain