Previous: Using the Generated VMS Build File Up: vimake

Using the Generated Unix Makefile

The generated Unix makefile is a fairly standard makefile. Since most VICAR programmers are not familiar with make, this section briefly describes how to use it. For more details on using make, see the documentation for it.

In a nutshell, a makefile describes the dependencies between parts of an application, and how to build those parts to create the output program. Dependencies are simply the files that are needed to build a piece of the program. For example, the executable depends on all the object files and the link libraries it needs. Each object file depends on its corresponding source file, and the include files that it uses. A link library depends on the object files that make it up. Source code may depend on a preprocessor, such as lex or yacc, or may come from a source code management system. All these dependencies can be tracked by make. make is smart enough to figure out what needs to be built based on what has changed, and to build only those parts. So, if you modify only one source module, make checks the modification dates, realizes only one module has changed, and recompiles only that module.

The vimake-generated makefile takes advantage of many of these features. It does not allow specifying which include files are used by which source files, but since VICAR applications are typically fairly small, this should not cause a problem. It may simply mean a few extra compiles. Full automatic dependency checking may be added to the makefile in the future.

By default, make looks for several filenames for the makefile, including ``Makefile'' and ``makefile''. However, the generated makefile is named `` file.make'' where file is the name of the application. Therefore, you must give the `` -f'' option to make to specify the name of the makefile. If you are doing lots of development on one program, you may rename the file to be ``Makefile'' (or better yet, create a symbolic link) so make will find it automatically, but this precludes having more than one application in the same directory, so it should not be done all the time. To run make, use the following syntax:


make -f file.make targets

where ``file'' is the name of the application and ``targets'' is an optional list of targets to build (described below).

make operates through the use of targets. A target is the final result of the make. A target could be an object file name, in which case that file would get compiled. It could be the executable name, in which case all the compiles and links necessary to create the executable are performed. There are also special targets, such as ``all'' or ``clean.src'', that cause certain actions to be performed. More than one target may be given on the same command, separated by spaces.

The targets available depend on whether you are building a PROGRAM, SUBROUTINE, or PROCEDURE, and on how complex the build is. The allowed targets are listed below. Not all targets will be available in all generated makefiles.

It is important to realize that there are fewer options on the makefile than there are on the VMS BLD file. This is largely due to the fact that make takes care of a lot of the details for you. You generally don't need to specify compiling a single module, or only doing the link, because make will determine what needs to be done and do it for you.

Some examples may prove helpful. The first example merely compiles a version of the program into the local directory:


make -f prog.make

The next example is the same, except the documentation (if present) is built as well:


make -f prog.make all

This example shows building the program for use in the debugger, for systems that support the ``debug'' target.


make -f prog.make debug

The last example shows how to delete the object modules after a build. This is not recommended during most program development, because it forces all the modules to be recompiled every time. However, it can be useful to force a recompile of everything on occasion.


make -f prog.make clean.obj

rgd059@ipl.jpl.nasa.gov