- 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:
- 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 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 ...
- 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.
- The UNIX make utility 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, by default trying
to create the first target.
- To build a target make first recursively treats each of the dependencies as targets, then if the target is either missing, or was created before any of its dependencies, make uses the actions to rebuild the target.
- Example of run
- The specific target that make tries to build can be specified on the command line. Example.
- 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 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 *.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