Document downloaded from:
http://www.doc.ic.ac.uk/~mac/manuals/sunos-manual-pages/sunos4/usr/local/man/man1/em2make.1.html
af, 01/Dec/2000
NAME
em2make - A Modula-2 Program Make Utility
SYNOPSIS
em2make [ options ] [ file ]
DESCRIPTION
em2make is a program for managing Modula-2 program develop-
ment. options specifies one or more control options, and
file is the name of a program file. A program file identi-
fies the source and object file components of a program. If
file is omitted em2make looks for a file called program or
Program in the current directory. If both are found, program
is selected in preference to Program
The simplest form of program file contains the line .UNITS
followed by a list of source file names. For example, a
small word processor package might be maintained with a pro-
gram file of the form
.UNITS
filer.def
filer.mod
formatter.def
formatter.mod
driver.mod
em2make works on the assumption that modules will be con-
structed with the module heading in a .def file and the
module block in a .mod file.
Because of the convention regarding file suffixes, the pro-
gram file above can be rewritten as
.UNITS
filer
formatter
driver.mod
When em2make finds a unit without a suffix, it treats this
as a shorthand for two units with the same base name but
with suffixes .def and .mod respectively.
On the first compilation of any program, em2make reads
enough of each source file to compute inter-module dependen-
cies. This information is then stored in a dependency file
whose name is derived by appending a .d suffix to the name
of the program file. In subsequent compilations, em2make
reads the dependency file and then updates the information
by re-analysing source files that have changed since the
last compilation. em2make will (re)compile a program unit if
the object file generated from the compilation does not
exist, or predates the source file of the unit, or predates
a definition module imported into the unit. During depen-
dency analysis, em2make will abort if it detects duplicate
or missing program units.
In the simple example above, em2make will initially cause
all units to be compiled and will result in the following
calls to the EPC Modula-2 compiler:
em2 -c filer.mod
em2 -c formatter.mod
em2 -c driver.mod
em2 filer.o formatter.o driver.o
The order in which the program units are compiled is deduced
automatically by em2make In the final link phase, the order
in which object files are presented to the linker is deduced
directly from the order in which units are listed in the
program file. The final order in which units are linked is
therefore controlled by the user.
In the example, the compiler is invoked with a default set
of options. This default set can be overridden by supplying
a substitute option set for individual units. For example, a
compilation listing of a unit may be obtained with
.UNITS
filer
formatter
driver.mod -c -G
In general, it is safer to specify a common set of options
for each kind of source file. This may be done by preceding
the list of UNITS with a list of COMPILERS to be used. For
example
.COMPILERS
em2 -c -w .def
em2 -c -w .mod
cc -c .c
tells em2make that all units held in .def or .mod files are
to be compiled by em2 using the options -c and -w and all
units held in .c files are to be compiled by cc using the -c
option.
When overriding the default compiler options, remember to
specify the -c option in order to suppress the link phase.
By default, em2make links units by passing an ordered list
of object file names to the compiler driver em2. In turn em2
appends the name of the Modula-2 runtime libraries to this
list and passes the complete list to the UNIX linker. This
process may be modified by including a LINKER statement in
the program file. For example,
.LINKER
em2 -s -o format
causes the options -s and -o to be passed to the linker
which in turn causes the stripped binary to be placed in the
file format. Further link time flexibility may be achieved
as follows:
(1) Additional object files may be passed to the linker by
including them in the UNITS list. Since they are dis-
tinguished by a .o suffix, they are ignored in the com-
pilation processing carried out by em2make Each object
file will be passed to the linker according to its ori-
ginal position in the UNITS list.
(2) Explicit access to the UNIX linker is possible simply by
substituting its name for em2 in the LINKER specifica-
tion. However, additional linker arguments which are
normally supplied automatically by em2 may need to be
passed manually. It is therefore advisable to check the
default set of options and libraries by first invoking
em2 with the -v option. This places the compiler driver
in `verbose' mode and causes it to display the command
lines that invoke the compiler and linker.
(3) Link processing may be suppressed completely by supply-
ing the -c option when em2make is invoked.
em2make may also be used to construct archive libraries. In
this case, the program file should contain a LIBRARY state-
ment which specifies the name of the archive file. In this
case em2make passes a list of object files to the UNIX
archive program ar(1) which creates a new archive with
members ordered according to the UNITS list. For example a
typical program file to construct a library of string han-
dling routines might be
.COMPILERS
em2 -c -w .def
em2 -c -w .mod
.UNITS
copystr
comparestr
searchstr
joinstr
readstr
writestr
.LIBRARY
libstrings.a
em2make assembles the library by inserting the .def files
and .o files derived by compiling the corresponding .mod
files. em2make may also insert a special member called
__.ALIASES which is read by the compiler and which allows
import statements to be mapped to the correct .def member in
cases where the definition module identifier is not the same
as the .def file name prefix.
On systems running AIX, the .def files would be put into a
companion library, in this case, called libstrings_x.a. The
library libstrings.a would still contain the object files.
This is because the AIX linker does not allow the mixing of
object files with other files types in an archive library.
The EPC Modula-2 compiler em2(1) also uses this _x conven-
tion on AIX systems when searching archives.
em2make will also handle definition module mappings for all
.def files appearing in the .UNITS list. Thus if a version
of a definition module TableManager is contained in the file
tableman12.def, em2make will create a file map.d with the
alias information
TableManager=tableman12.def
and all modules that import TableManager are compiled with
em2 -c -f map.d ...
The program files used by em2make may be documented by
including comments. A comment line is marked by a '#' char-
acter in column one. The rest of the line is ignored by
em2make. A complete program file for the document formatter
might be
# program file for format
#
.COMPILERS
em2 -c -w .def
em2 -c -w .mod
.UNITS
filer
formatter
driver.mod
.LINKER
em2 -s -o format
Additional control over em2make may be exercised by a small
number of control options. These are as follows.
-n Analyses which modules need recompilation but
suppresses the actual compilations. This is useful
if it is desirable to see in advance which modules
will be recompiled.
-a Unconditionally recompiles all program modules.
-d Writes an inter-module dependency analysis to the
standard output stream. This consists of all the
compilation units presented in the order in which
they will be recompiled. The set of imported modules
is listed with each unit.
-v Outputs a version/release number.
-w Suppresses warning messages.
SEE ALSO
em2(1), EPC Modula-2 Compiler.
EPC Modula-2 User's Reference Manual, Edinburgh Portable
Compilers Limited, 1991.
DIAGNOSTICS
The diagnostics produced by em2make are intended to be self
explanatory.
Last Change: EPCL