Logo Search packages:      
Sourcecode: ksh version File versions  Download package

nmake.mm

.xx noindex
.MT 4
.TL

.H 1 Introduction
.BR nmake (1)
is the standard software construction tool at AT&T and
Lucent Technologies.
It is a descendent of the UNIX
.BR make (1)
and is not related to the
.xx link="http://msdn.microsoft.com/library/en-us/vcug98/html/_asug_overview.3a_.nmake_reference.asp  Microsoft program"
of the same name.
.P
Some of the
.B nmake
features described in this overview are:
.BL
.LI
Portable makefiles that are OS and compiler independent.
.LI
Automatic dynamic dependency checking based on file type.
.LI
Automatic recursive make ordering.
.LI
Excellent performance that scales to 10K file, 10M line projects.
.LI
An extensible programming language.
.LI
Parallel execution.
.LI
Many common actions
.RB ( install ,
.BR clobber ,
.BR list.manifest ,
etc.)
provided by default.
.LI
Makefile sizes typically 10 times smaller than
.BR make .
.LI
State based execution.
.LI
Source in multiple directories.
.LI
Viewpathing.
.LI
Portable external package naming.
.LI
Native command, archive and shared library generation.
.LI
No
.BI auto this ,
.BI config that
or
.IB foo tool
commands, no makefile generation, no
.LR "make depend" ,
no separate manifests;
just
.BR nmake .
.LE

.H 1 History
.B nmake
was created and enhanced by Glenn Fowler of AT&T Labs Research.
It began in 1984 as
.B make
with a makefile
.BR cpp (1)
(C preprocessor) front end.
It soon evolved into a separate implementation with a language
rich enough to make preprocessed and generated makefiles obsolete.
The first internal release was in 1985 and the first external open source
release was in 2000.
The current release is available in the
.B ast-base
and
.B ast-open
packages at
.xx link="/sw/download/ Software Systems Research software;"
there is also a
.xx link="/sw/download/faq.nmake.html     FAQ."
Although
.B nmake
makefiles are not compatible with UNIX
.B make
or Microsoft
.BR nmake ,
.B nmake
can generate UNIX
.B make
or Microsoft
.B nmake
style makefiles for porting and bootstrapping.

.H 1 Overview
This is a brief overview of common user-level
.B nmake
features used by the component makefiles of the
.xx link="/sw/download/ ast-open"
source package.
Although slightly out of sync with the AT&T release, the
.xx link="http://www.alcatel-lucent.com/  Alcatel-Lucent (search for nmake -- who mourns for Bell Labs?)"
site provides a more complete treatment of the details
(the tech writer remained with Lucent after the '95 split.)
The following assumes familiarity with the UNIX or GNU
.B make
program.
There is a glossary of terms in the appendix; the first reference to
each term is in italics.

.H 1 Makefiles
Similar to UNIX
.BR make ,
.B nmake
input is a
.I makefile
consisting of a set of
.I assignments
and
.IR assertions .
By default
.B nmake
searches for a file named
.LR Nmakefile ,
.LR nmakefile ,
.LR Makefile ,
and then
.L makefile
in that order.
A common convention is to use the
.L .mk
suffix when naming makefiles and invoke
.B nmake
with
\f5-f\fP \fIname\fP\f5.mk\fP.
.P
Unlike UNIX makefiles, an
.B nmake
makefile is compiled by reading the makefile,
carrying out the assignments, and creating rules from the assertions.
The compiled makefile name is formed by adding a
.L .mo
suffix to the makefile name if it does not have a
.L .mk
suffix or by changing the
.L .mk
suffix to
.LR .mo .
In addition to the assertions and assignments in the input makefile,
.B nmake
uses a precompiled
.I "base rules"
file and, if defined,
.I "global rules"
files when compiling the makefile.
The makefile is implicitly compiled whenever it,
the base rules, or any referenced global rules file changes.

.H 1 Comments
.B nmake
supports C style comments as well as
.L #
style comments that appear after one or more space characters.
Earlier versions of
.B nmake
passed makefiles through the C preprocessor.
Although still supported, it is now deprecated
in lieu of newer language features.
(It hasn't been dropped because there are still a few legacy projects
that rely on makefile preprocessing.)

.H 1 Assertions
An
.B nmake
assertion is a generalization of a
.B make
assertion.
It consists of a
.I "target list"
(the left hand side), an
.IR operator ,
and a
.I "prerequisite list"
(the right hand side.)
The operator may either be
.L :
as in
.BR make ,
or of the form
\f5:\fP\fIname\fP\f5:\fP where
.I name
is the null string or an alphanumeric.
Many operators of the latter form are defined in the base rules.
Additional operators can be defined in global and user makefiles.
A description of how to define new operators is beyond the scope of this
introduction.
.P
For example, the line
.EX
prog : prog.o prog.h -lm
.EE
specifies that the target
.L prog
depends on the prerequisites
.LR prog.o ,
.L prog.h
and
.LR -lm .
.P
Indented lines after each assertion, if any, define an
.I action
block associated with the assertion.
Unlike
.BR make ,
.B nmake
actions are multi-line blocks that are executed as a unit.
To execute a shell action block,
.B nmake
expands any
.B nmake
variables and then passes the block to the shell for execution.
This allows action blocks to contain shell here documents and
multi-line structured statements without the need for extra quoting.
This is extremely difficult to do in
.BR make ,
where actions are executed one line at a time.
.P
The shell action trace is done by the shell as each command is executed
using the
.BR sh (1)
.L -x
option.
Tracing can be turned off for a target by specifying
.L "set +x"
as the first command in its action block.
Tracing can be turned off for an individual command by prefixing it with
.LR silent :
.EX
test_silent :
      silent echo this will not echo '"+ echo ..."'
.EE
By default a shell action block fails and is terminated when any command
returns non-0 exit status, excluding commands subject to
.LR if ,
.LR while ,
.LR ! ,
.L ||
or
.LR && .
The exit status can be ignored for all commands in a target action
by asserting the
.B .IGNORE
attribute on the target.
The exit status for an individual command can be ignored by prefixing it with
.LR ignore :
.EX
test_ignore :
      ignore false
      echo the first false is ignored
      false
      echo but the second causes the action to fail and skip this echo
.EE
.L silent
and
.L ignore
are implemented as shell functions or aliases, depending on the shell path,
determined by searching for the following {
.B $COSHELL
.B $SHELL
.B ksh
.B sh
.B /bin/sh
}
in order on
.BR $PATH.
.P
The collection of assertions associated with a given target
together defines a
.I rule
for the target.
In most cases a rule is defined by a single assertion,
so the two terms are often used interchangeably.
.P
Both prerequisites and targets can represent many different types of objects.
They may be names of files, names of
.IR "state variables" ,
names of rules, or
.IR attributes .
A state variable is a variable that has both a value and a time stamp;
when the variable value changes its time stamp is also changes.
Attributes are special reserved words that are understood by
.B nmake
itself.
Attribute names all begin with a
.L .
and are all upper case.
The full list of attributes and their meaning can be found in the
Alcatel-Lucent documentation.
An example of an attribute is
.L .MAKE
which marks an action block to be executed by
.B nmake
rather than the default shell.
This is used in the base rules to define many
of the default rules and assertion operators.
An attribute that is often found in user makefiles is
.LR .DONTCARE .
It is normally a fatal error when a prerequisite cannot be found or made;
asserting the
.L .DONTCARE
attribute on the target:
.EX
\fItarget\fP : .DONTCARE
.EE
inhibits the error.
.P
A target whose name contains the character
.L %
defines a special type of rule called a
.IR metarule .
A metarule matches files using the
.L %
like the shell
.L *
wild card.
Metarules are common in the base and global rule files
and are used on occasion inside user makefiles.

.H 1 "Assignments and Variables"
An assignment can be one of the following four types:
.BL
.LI
A simple assignment of the form \fIname\fP \f5=\fP \fIvalue\fP
that delays the expansion of
.I value
until
.I name
is expanded.
.LI
A simple assignment of the form \fIname\fP \f5:=\fP \fIvalue\fP
that expands
.I value
before being assigned to
.IR name .
.LI
A append assignment of the form \fIname\fP \f5+=\fP \fIvalue\fP
that appends the expanded
.I value
to the current value of the variable
.IR name .
.LI
A state variable assignment of the form \fIname\fP \f5==\fP \fIvalue\fP.
.B nmake
scans source files for state variable references and
keeps track of changes to their values.
A state variable can be used as a prerequisite or a target by
specifying \f5(\fP\fIname\fP\f5)\fP.
.LE
.P
Variables are referenced using the notation \f5$(\fP\fIname\fP\f5)\fP
where \fIname\fP is the name of the variable.
In addition each
.I name
can be followed by a
.L :
separated list of expansion operators
that operate on each space separated token in the result of the expansion.
For example, the operator
\f5:N=\fP\fIpattern\fP\f5:\fP
selects tokens that match the shell
.I pattern
and the operator
\f5:T=F:\fP
binds each token to a file and expands the token to the bound path name.
.EX
FILES = main.c stdio.h
print $(FILES:N=*.h:T=F)
.EE
would print
.L /usr/include/stdio.h
on most UNIX systems.
The complete list of expansion operators can be found in the
Alcatel-Lucent documentation.
.P
.B nmake
uses certain conventions for naming related variables.
For example, while the variable
.L CC
names the C compiler as with
.BR make ,
other C compiler related variables also begin with
.LR CC .
Thus, the variable name
.L CCFLAGS
is used rather than
.LR CFLAGS .
In addition, other variables of the form
\f5CC.\fP\fIname\fP
are used to parameterize portable rules and assertion operators.
These are
.IR "probe variables" ,
described in the next section.
In general the user modifiable variables for
.I TOOL
are named
.I TOOLidentifier
and the the corresponding probe variables are named
.IR TOOL.identifier .
.P
.I "Special variables"
are readonly variables maintained by
.BR nmake .
They are used in actions and have values relative to the current
target and prerequisites.
Each special variable name is a single non-alphanumeric character that
may be repeated to access ancestor values, e.g.,
.L "$(<)"
names the current target,
.L "$(<<)"
names the parent target of the current target.
Special variable names may also be used as a rule name prefix to access
information about that rule, e.g.,
.L "$(*.SOURCE.h)"
expands to the prerequisites of the
.L .SOURCE.h
rule.
.P
Special variables are indispensable for several reasons:
.BL
.LI
bound file names are expanded; this is required for viewpath and
.L .SOURCE*
binding
.LI
.IR "specify once and right" :
rules can specify target and prerequisite names once, avoiding errors
caused by out of sync duplication
.LI
portions of rules can be shared, .e.g, edit operators applied to
\f5$(@\fP\fIrule\fP\f5)\fP
.LE
.P
The special variables are:
.VL 6
.LI
.L "$(<)"
The target name.
This may be a list for
.B .JOINT
rules that generate multiple targets from one action.
.LI
.L "$(>)"
The out of date file prerequisites.
This variable is most often used in metarule actions.
.LI
.L "$(*)"
All file prerequisites.
.LI
.L "$(~)"
All prerequisites.
.LI
.L "$(@)"
The action block.
.LI
.L "$(%)"
The metarule target stem or
.L .FUNCTIONAL
arguments.
.LI
.L "$(!)"
Explicit and generated file prerequisites.
.LI
.L "$(&)"
Explicit and generated state prerequisites.
.LI
.L "$(?)"
All explicit and generated prerequisites.
.LI
.L "$(^)"
The original bound name.
A generated target may bind to a file in another directory.
If the target is out of date then
.L "$(<)"
is the target name to be generated, and
.L "$(^)"
is the original name.
For example, a makefile that generates
.L ./libfoo.a
and installs
.L "$(LIBDIR)/libfoo.a"
may bind
.L -lfoo
to
.L "$(LIBDIR)/libfoo.a"
before
.L ./libfoo.a
is generated.
In this case
.L "$(^)"
is
.L "$(LIBDIR)/libfoo.a"
and
.L "$(<)"
is
.LR libfoo.a .
.LI
.L "$(-)"
The current
.B nmake
options, suitable for the command line.
This is a global special variable and is not target related.
\f5$(-\fP\fIoption\fP\f5)\fP
expands to the current setting for
.IR option .
.LI
.L "$(+)"
The current
.B nmake
options, suitable for the
.B nmake
.L set
builtin.
This is a global special variable and is not target related.
\f5$(+\fP\fIoption\fP\f5)\fP
expands to the current setting for
.IR option .
.LI
.L "$(=)"
The command line and
.L .EXPORT
variable settings, suitable for the command line.
This is a global special variable and is not target related.
.LI
.L "$(...)"
The list of all rules and attributes.
This special variable is often used with attribute or pattern match
edit operators.
For example,
.L "$(...:A=.TARGET)"
expands to the names of all target rules and
.L "$(...:N=*.o:T=F)"
expands to the bound names of all rules matching the shell pattern
.L *.o
that bind to existing files.
.LE

.H 1 "Make Probe Information"
The base rules conform to local OS conventions using information generated
by the
.BR probe (1)
command.
Probe information is maintained for each compiler in directories shared
by all users.
Currently
.B nmake
uses
.B make
and
.B pp
(C preprocessor) probe information.
The information is automatically generated and updated when the corresponding
.B probe
script changes.
.P
The make probe information is a set of variable definitions, all of the form
.BI CC. name.
See
.xx link="../probe/probe.html probe information"
for details.
Typical user makefile make probe variables are:
.VL 6
.LI
.B CC.DEBUG
The
.B cc
option that enables object file debugging information.
.LI
.B CC.DLL
The
.B cc
option(s)
required for shared library object files.
.LI
.B CC.HOSTTYPE
The target architecture host type as determined by
.BR package (1).
.LI
.B CC.OPTIMIZE
The
.B cc
option that enables optimization.
.LI
.B CC.WARN
The
.B cc
option that enables verbose warning and error messages.
.LE

.H 1 "Assertion Operators"
.B nmake
makefiles typically use one or more higher level operators, and more
often than not skip the primitive
.LR : .
This section introduces some commonly used operators.
.P
The
.L ::
operator, whose
.I name
is the null string,
expects source file prerequisites rather than intermediates.
The
.L ::
operator is defined in the
.IR "base rules" .
It generates primitive assertions and actions based
on prerequisite file suffixes use base rule
.IR metarules .
The base rules correspond to the
.B makerules.mo
global rules file, provided with every
.B nmake
installation.
The base rules are read by default before any user makefiles are read.
.P
For example, the makefile
.EX
DEBUG == 1
prog :: prog.y helper.c -lxyz
.EE
specifies that the target program
.L prog
is constructed from the object files generated by
.LR prog.y ,
.L helper.c
and
.LR -lxyz ,
and that object file generation may depend on the variable
.LR DEBUG .
In this case if either
.L prog.c
(and/or
.LR helper.c )
contains the symbol
.L DEBUG
then the C compilation flags for
.L prog.o
(and/or
.LR helper.o )
will contain
.LR -DDEBUG .
In addition, if the value of
.L DEBUG
changes for some future invocation of
.B nmake
then
.L prog.o
(and/or
.LR helper.o )
will be recompiled with that new value.
.P
There are many other operators defined in the base rules.
The \f5:LIBRARY:\fP operator generates both
static and dynamic libraries:
.EX
CCFLAGS = $(CC.OPTIMIZE) $(CC.DLL)
xyz 4.0 :LIBRARY: xyz.c strmatch.c
$(INCLUDEDIR) :INSTALLDIR: xyz.h
.EE
The example makefile generates and installs both a static and shared library
named
.BR xyz .
.L $(CC.OPTIMIZE)
generates optimized object files and
.L $(CC.DLL)
generates object files suitable for shared libraries, and also instructs
.L :LIBRARY:
to generate a shared library.
The
.BR probe (1)
information determines the corresponding library file names.
For example, on linux these would be installed:
.EX
$(INCLUDEDIR)/xyz.h
$(LIBDIR)/libxyz.a
$(LIBDIR)/libxyz.so
$(LIBDIR)/libxyz.so.4.0
.EE
on win32 systems these would be installed:
.EX
$(INCLUDEDIR)/xyz.h
$(LIBDIR)/libxyz.a
$(LIBDIR)/xyz.lib
$(BINDIR)/xyz40.dll
.EE
and on
.B cygwin
systems these would be installed:
.EX
$(INCLUDEDIR)/xyz.h
$(LIBDIR)/libxyz.a
$(LIBDIR)/libxyz.dll.a
$(BINDIR)/cygxyz40.dll
.EE
The
.L :LIBRARY:
operator also deletes all static library object files after they have been
added to the static library;
.B nmake
is able to scan the libraries to determine the object file time
stamps using the
.BR libardir (3)
library, also used by
.BR pax (1).
.B libadir
mitigates the differences between vendor archive implementations.
.P
The
.L :PACKAGE:
operator provides portable and consistent external package references.
It appends package include directories, if any, to
.L .SOURCE.h
and package library directories, if any, to
.LR .SOURCE.a .
It also links all command and shared library targets with default
package libraries.
When a package cannot be found all other rules are disabled and
.B nmake
exits with a diagnostic message.
.EX
:PACKAGE: games X11

xgame :: README xgame.6 xgame.h xgame.c xutil.c -lXaw -lXmu -lXt

$(INCLUDEDIR) :INSTALLDIR: xgame.h
.EE
This example specifies that the command source files may reference the X11
headers, and the command executable links against the default X11 libraries,
along with the explicit X11 libraries
.BR -lXaw ,
.B -lXmu
and
.BR -lXt .
The first prerequisite of all
.L :PACKAGE:
assertions is the main package; the main package modifies the header
installation directory by appending the package subdirectory.
.L -
as the first prerequisite of
.L :PACKAGE:
specifies that the package is external.
For this example the main package is
.LR games ,
and
.L $(INCLUDEDIR)
is
.LR $(INSTALLROOT)/include/games .
.P
Many rules provided by the base rules
must be explicitly asserted in UNIX
.B make
makefiles.
For example, the rules
.LR clean ,
.L clobber
and
.L install
are predefined in the base rules, making them
unneeded in user makefiles.
In addition, the
.L pax
and
.L tgz
rules produce
.RB tar (1)
format archives containing source files defined explicitly or implicitly
by the makefile.
A source file is any local non-generated file that is used to generate a
target file.
To specify files that need to be part of the source archive
that are neither referenced in the Makefile or are implicit
prerequisites, use the \f5::\fP operator without any targets.
For example:
.EX
:: README Install Copyright
.EE
adds these files to the generated
.B pax
file when
.B nmake
is invoked with the target
.BR pax .

.H 1 "State File"
A major difference between
.B nmake
and
.B make
is that
.B nmake
uses results from previous runs
to decide what needs to be built.
This information is stored in a file called the
.IR "state file" .
The state file name is formed by adding a
.L .ms
suffix to the makefile name if it does not have a
.L .mk
suffix or by changing the
.L .mk
suffix to
.LR .ms .
The state file retains the following information:
.BL
.LI
File and event times for all generated and terminal files.
.LI
Explicit prerequisite lists.
.LI
Implicit prerequisite lists.
.LI
Action blocks used (before expansion.)
.LI
State variable values.
.LI
Target attributes.
.LE
If any of these have changed for a particular target then the target
is marked out of date.
This is a fundamental departure from
.BR make .
In particular, file time changes into the past or future are detected.
When a change is detected for a target its event time is set to
.IR now ,
and it is this time that is propagated to dependent targets.
.P
The
.I "implicit prerequisites"
are generated by applying
.I "scan rules"
to source files.
The scan rules themselves are specified by the
.L .SCAN
attribute.
The
.L .SCAN
attribute specifies that the action block is a scan description.
A scan description describes the commenting and quoting rules
as well as the syntax for identifiers, includes and conditional compilation.
Include files found within conditional compilation are
given the
.L .DONTCARE
attribute.
Only
.L .DONTCARE
files that exist will be tracked as implicit prerequisites; non-existent
.L .DONTCARE
files are silently ignored.
The scan rules are typically metarules that match files with
a given suffix.
In addition to scanning for include dependencies,
the scan rules check for state variable dependencies
by checking for state variable name matches within the scanned source files.
The base rules contain the scan rules for several
languages including C and C++.
.P
Implicit prerequisite generation is dynamic and incremental.
If a source file has changed from the last time it was scanned then
it is scanned again.
In addition,
if making a rule causes a file to be generated, and the file
that it generates matches a scan metarule, then the generated
file is scanned for dependency information.
This is in contrast with most
.B make
dependency generation tools that either generate this information statically
or collect it as a by-product of compilation
(requiring special compiler hooks.)
The latter technique is prone to
.I off-by-one
compile errors where generated include dependencies may not be noticed by
.B make
until after the compiler runs (and fails.)
.P
The scan information is saved in the state file so that
a file only needs to be scanned again if it has changed.
The state file also stores the value of state variables.
The base rules define variables such as \f5CC\fP and
\f5CCFLAGS\fP to be state variables so that a change
of compiler or compile options triggers recompilation.

.H 1 "Binding and Making"
The process of associating a target or prerequisite
with a physical object such as a file, rule or state variable is called
.IR binding .
The handling of directory searches for binding is described in the
.B "Multiple Directories"
section below.
.P
Names of the form \f5(\fP\fIname\fP\f5)\fP
are bound to state variables.
Names that contain a \f5%\fP are bound to metarules.
Other names may be bound to rules or to filenames.
.P
Libraries can be specified as either \f5-l\fP\fIlib\fP
or \f5+l\fP\fIlib\fP.
On systems that support both dynamic libraries and static libraries,
\f5-l\fP\fIlib\fP will prefer dynamic linking when both dynamic and
static versions of the library are present, whereas \f5+l\fP\fIlib\fP
will prefer the static library.
The dynamic/static preference is on a per-directory basis.
.P
The fundamental
.B nmake
operation is to
.I make
a target.
.B nmake
makes a target by recursively making each of its prerequisites.
To make a given prerequisite, it is first bound.
If it binds to a rule, then the targets for that rule are made.
If the prerequisite binds to a file or a state variable,
and
.B nmake
determines that it needs to be updated,
then the action for that file or state variable is executed.
.P
The method that
.B nmake
uses to determine whether a target needs to be
updated differs from that of
.BR make .
With
.BR make ,
if the file time of the target is older than
that of any of the prerequisites, then the action is triggered.
With
.B nmake ,
if the time of any of the prerequisites
saved in the state file differs (older
.I or
newer) from the time of the file
then action is triggered.
Moreover, if the action completes successfully, the time stamp of the target
is recorded in the state file even if it has not changed.
In this way an action need not change the time stamp
of the target if no change is needed, preventing
anything that depends on this target from being remade.
Another consequence of this model is that restoring an
old source file with the old time stamp is detected as a change by
.BR nmake .
For the first build, when there is no statefile, or
when the accept option, \f5\-A\fP, is specified on
the command line,
.B nmake
uses the
.B make
time stamp model.
.P
The actions for the prerequisites of a given target may be executed in any order;
they may even be executed concurrently.
.P
When
.B nmake
is invoked it makes the rules
.LR .INIT ,
.L .MAIN
and
.LR .DONE ,
in that order.
By default the prerequisite of
.L .MAIN
is the first user makefile target, usually
.L all
or
.L .ALL
defined by the
.L ::
assertion operator.

.H 1 "Multiple Directories"
Unlike
.BR make ,
.B nmake
supports a multiple directory model.
There is no reason that the files specified in the
makefile need to reside in a single directory.
It is often convenient to partition the source for a single makefile into
many subdirectories.
The
.B nmake
.L .SOURCE
rule specifies the directories (and directory order) to be searched
for prerequisite source files.
For example,
.EX
\|.SOURCE : lib common
.EE
specifies that the
.L lib
and
.L common
directories are to be searched, in that order,
when binding names to files.
The current directory
.L .
is always searched first.
In addition, source rules for searching files of any suffix
can be specified by using the target \f5.SOURCE.\fP\fIsuffix\fP.
Using source assertions for include files has another advantage.
The \f5::\fP and the \f5:LIBRARY:\fP operators use the \f5.SOURCE.h\fP
assertion to generate \f5-I\fP directives
for the C or C++ compilers.
.L -I
directives are generated only for directories containing files used for each
compilation.
.P
The ability to specify multiple search directories
eliminates the need for nested makefiles in many cases.
However, it is only useful for building something in
which all component names are known.
Large project management requires recursive makefiles.
Recursive
.B nmake
is
.I not
considered harmful; it is most emphatically
.I essential
for composing complex systems from smaller components.
The base rules supply the
.L :MAKE:
operator for this purpose.
With no prerequisites
.L :MAKE:
determines the build order for all subdirectories that contain a makefile.
Subdirectory makefiles may themselves contain
.L :MAKE:
operators, and these are handled recursively.
Project directory hierarchies typically have top level makefiles containing
a single
.L :MAKE:
assertion;
.B nmake
run at the top level will recursively run
.B nmake
in all subdirectories
.I "in the proper order" .
Subdirectory ordering is determined by
.L :PACKAGE:
assertions and
\f5-l\fP\fIlib\fP
and command prerequisites.
.P
The most important aspect of
.L :MAKE:
is that
.I "component directories"
can be added to or deleted from a directory hierarchy and the next
.B nmake
run will take these changes into account, without the need to modify
global project files or scripts.

.H 1 Viewpathing
Keeping source and generated files separate eases
file management when multiple target architectures are involved.
There are several ways to do this:
.BL
.LI
Make a complete copy of the source tree for each architecture:
although easy to manage, this technique is not space efficient.
And, since there are multiple copies of the source,
it's hard to keep the separate source copies from diverging.
.sp
.LI
Make architecture specific subdirectories for each source tree leaf directory:
this is much more space efficient since all architectures share one
copy of the source.
However, isolating the files for one particular architecture is non-trivial,
since architecture specific directories are distributed throughout the
entire source tree.
.EX
             package-root
               .  .  .
              .   .   .
             .    .    .
            .     .     .
           .      .      .
          .       .       .
         .        .        .
        bin      lib      src
        . .      . .      . .
       .   .    .   .    .   .
      A1   A2  A1   A2  lib cmd
                        .     .
                       .       .
                      .         .
                     .           .
                   libar         foo
                    . .          . .
                   .   .        .   .
                  A1   A2      A1   A2
.EE
.LI
Make a directory tree copy of the source tree (just directories, no files)
for each architecture and make a symlink in the copy for each regular file
in the source tree: this is space efficient and isolates the architecture
specific files under a separate tree.
It is too easy, however, to clobber original source files from within
the architecture specific trees.
.sp
.LI
Make a directory tree copy of the source tree (just directories, no files)
for each architecture and viewpath the architecture tree on top of the
source tree:
this is space efficient and safely separates source from generated files.
.EX
                         package-root
                         .          .
                    .                    .
               .                              .
              src                            arch
             .   .                          .    .
            .     .                      .          .
          lib     cmd                 .                .
          .         .                A1                A2
         .           .               .                  .
        .             .              .                  .
      libar          foo             .                  .
                                    src                src
                                   .   .              .   .
                                  .     .            .     .
                                 lib   cmd          lib   cmd
                                 .       .          .       .
                                .         .        .         .
                              libar      foo     libar      foo
.EE
Viewpathing also allows multiple source trees to be chained together;
this means that source from separate package root directories can be shared.
This technique is useful for isolating local developer debug and enhancement
modifications from the master source.
Viewpaths are specified in the
.L VPATH
environment variable as a
.L :
separated list of root directories:
.EX
VPATH=\fIdeveloper-root\fP:\fIHOSTTYPE-root\fP:\fImaster-root\fP
.EE
If the local host supports DLL preload then the
.BR 3d (1)
command can be used to provide a transparent viewpath view to all
dynamically linked commands.
The
.L VPATH
environment variable provides the initial view, and additional views are
specified with the
.BR ksh (1)
.BR vpath (1)
builtin:
.EX
vpath \fIdeveloper-root\fP \fIHOSTTYPE-root\fP
vpath \fIHOSTTYPE-root\fP \fImaster-root\fP
.EE
.LE

.H 1 Portability
The best way to achieve portability with
.B nmake
makefiles is to
.BL
.LI
specify as little as possible
.LI
use
.BR probe (1)
abstractions, e.g.,
.LR CC.DLL ,
.LR CC.SUFFIX.ARCHIVE ,
etc.
.LI
use predefined base rules operators and variables
.LI
specify all source for all systems and select via
.LR #ifdef s
in the source
.LI
avoid constructs that depend on a particular system or compiler
.LI
avoid makefile conditionals
.LI
avoid absolute pathnames
.LI
do not use explicit
.L -D
or
.L -I
options; define state variables for
.L -D
and
.LR .SOURCE *
assertions for
.L -I
.LI
use
.L .DONTCARE
for libraries that may not be on all systems; better yet, make them
prerequisites in
.L :LIBRARY:
assertions
.LI
use
.BR iffe (1)
to generate configuration dependent headers
.LE
.P
The
.B nmake
base rules ensure that the
.BR probe (1)
abstractions and default rules, operators and variables
function equivalently on all systems.

.H 1 iffe
.BR iffe (1)
(if feature exists)
is a tool that generates configuration header files based on information
probed from the current
.L "$(CC)"
and native system.
.B iffe
processes files that are normally stored in a
directory named
.LR features .
The resulting header files are stored in the directory named
.L FEATURE
.RI ( not
the more intuitive
.L FEATURES
to appease case ignorant filesystems.)
.B iffe
enabled source includes these files
and uses the generated macros in conditional compilation tests.
.P
.B iffe
is able to probe any non-interactive target system behavior through
user specified C programs and shell scripts.
However, many common precoded queries can be leveraged to produce simple
and compact
.B iffe
scripts:
.BL
.LI
Does header file \fIname\fP\f5.h\fP exist as a standard header?
.EX
hdr   \fIname\fP
.EE
.LI
Does header file \fIsys/name\fP\f5.h\fP exist as a standard header?
.EX
sys   \fIname\fP
.EE
.LI
Does the type \fItype\fP exist when
.B sys/types.h
and/or a given set of standard include files are included?
.EX
typ   \fIname\fP  [ \fIheader\fP.h ... ]
.EE
.LI
Is the function \fIname\fP in the standard library or one of
the given libraries?
.EX
lib   \fP\fIname\fP     [ \f5-l\fP\fIlib\fP ... ]
.EE
.LI
Is the data symbol \fIname\fP in the standard library or one of
the given libraries?
.EX
dat   \fP\fIname\fP     [ \f5-l\fP\fIlib\fP ... ]
.EE
.LI
Is the symbol \fIname\fP a member of a given structure when
a given set of files is included?
.EX
mem   \fIstruct_name.member_name\fP [ \fIheader\fP.h ... ]
.EE
.LI
Is the command \fIname\fP found on the standard path?
.EX
cmd   \fIname\fP
.EE
.LE
Wherever an \fIoperator\fP or \fIname\fP can be specified, a comma separated
list of names can be specified, and the test will
be performed for each \fIoperator\fP and \fIname\fP in the list:
.EX
hdr,sys     stdio,fcntl,socket,mman
.EE
.P
Unlike
.BR configure (1) ,
.B iffe
generated macro names conform to a strict and consistent naming convention.
See
.BR iffe (1)
for more details.
For compatibility the
.L -C
or
.L --config
option can be used to coax
.B iffe
to generate
.BR configure (1)
\f5HAVE_\fP\fIfeature\fP style macros.
Converting from
.B configure
to
.B iffe
is worth the effort, for portability, stability, and size.
The corresponding
.B iffe
scripts are typically more compact and clearly delineate generated vs.
source files -- you didn't really think someone hand-coded that 10K line
.B ImageMagick
configure script.
Our equivalent
.B iffe
script is less than 100 lines.
Granted,
.B iffe
is implemented as a 4K line shell script, but
.I that
script remains constant across all projects.
We have some
.B iffe
scripts, still in use, that haven't changed since 1994.
.P
The base rules provide complete support for
.BR iffe (1)
through these metarules (action blocks omitted):
.EX
FEATURE/% : features/%
FEATURE/% : features/%.c
FEATURE/% : features/%.sh
% : %.iffe
.EE
Since
.B nmake
does automatic implicit prerequisite analysis, a source files need only
.EX
#include "FEATURE/\fP\fIfoo\fP\f5"
.EE
and \f5FEATURE/\fP\fIfoo\fP will be automatically generated/updated before
any dependent file is compiled.
.P
.B nmake
is known to work on these
.xx link="/sw/download/arch.html    architectures."
Although architecture independent makefiles is a prime portability goal, some
architecture specifics are unavoidable.
For the
.B ast
software most of these correspond to C compiler optimizer bugs,
i.e., generated code works fine without
.L "$(CC.OPTIMIZE)"
in
.L CCFLAGS
but fails with it set.
The base rules
.L :NOOPTIMIZE:
assertion operator provides per-file control over optimization:
.EX
CCFLAGS = $(CC.OPTIMIZE)

cmd :: a.c b.c c.c

"sol?.i386|sgi.*" :NOOPTIMIZE: b.c
.EE
This makefile disables C compiler optimization for
.L b.c
on
.L "$(CC.HOSTTYPE)"
architectures that match
.L sol?.i386
or
.LR sgi.* .

.H 1 Execution
.B nmake
can be run in command mode or interactively.
.L "nmake -n query"
enters the query mode;
rule names, assignments and assertions may be entered at the
.L "make>"
prompt.
Entering a name with no operators lists all variable and rule information
for that name.
State rule names are indicated by a balanced parenthese prefix followed
by the rule name, and state variable names are entirely enclosed
in parenthesis.
Query mode is especially helpful for writing and debugging rules.
.P
The \f5\-n\fP option of
.B nmake
is similar to that of
.BR make ,
except that targets with the
.L .ALWAYS
attribute are still executed.
The
.L -N
option inhibits all shell action execution.
The
.L -n
is passed to recursive
.B nmake
invocations (via \f5:MAKE:\fP assertions) using the
.L "$(-)"
special variable.
.P
When make begins execution, it looks for a file named
.L Makeargs
or
.L makeargs
in the current directory.
If found, each line of the file is inserted into the command line
option list.
This allows local additions/overrides without the need to modify
the underlying makefile, which may be on a different viewpath level.
For example a
.L Makeargs
file containing
.EX
--debug-symbols
.EE
will compile with compiler debugging flags enabled.
.P
Before the first action is executed
.B nmake
starts a single shell process, called the
.IR coshell ,
to execute all action blocks.
This cuts down on
.B nmake
.BR fork (2)
or
.BR spawn (2)
overhead and allows command execution to be handled by the most
efficient program.
While an action is executing
.B nmake
determines the next action to execute.
The \f5-j\fP\fInproc\fP option, or the \f5NPROC=\fP\fInproc\fP environment
variable allows
.B nmake
to execute
.I nproc
actions simultaneously.
Internally
.B nmake
builds a dynamic prerequisite graph;
this graph determines target actions that may execute concurrently.
The
.B .SEMAPHORE
attribute provides per-target concurrency control.
The
.B coshell
program is determined by the
.B COSHELL
or
.B SHELL
environment variables, checked in that order,
or
.L /bin/sh
by default.
.L COSHELL
may also point to
.BR coshell (1)
which supports concurrent action execution on separate hosts that share
the same filesystem.
.P
Sometimes it is necessary to circumvent the
.B nmake
state model.
For instance, the
.B ast
software bootstrap build uses
.BR mamake (1)
to build
.BR nmake .
If
.B nmake
were to be run on the bootstrap generated files they would be rebuilt
since the bootstrap provided no
.B nmake
state.
The
.L --accept
or
.L -A
option instructs
.B nmake
to use the
.B make
time stamp model and accept files that are up to date with respect to file
time stamps only.
An up to date state file is generated so that subsequent invocations,
with no other changes, will treat all files as up to date.
.L --accept
is often used with the
.L --touch
or
.L -t
option that sets the time stamp of all out of date generated files
to the current time.

.H 1 Variants
There are now three public variants of
.I make
named
.BR nmake :
.VL 6
.LI
.B "AT&T nmake 5.0"
This is the version maintained by the original author.
.LI
.B "Lucent nmake 3.5"
The the variant that split in 1995 when AT&T spun off Lucent.
.LI
.B "MicroSoft NMAKE"
This variant has some features inspired by the 1985 Portland USENIX paper,
but that's where the similarities end.
.LE
.PP
Use
.EX
nmake -n -f - . 'print $(MAKEVERSION)'
.EE
to list the installed
.B nmake
version.
.P
Here are the known incompatibilities between the AT&T and Lucent
variants.
Bug fixes and backwards compatible enhancements to the AT&T variant
are not listed.
.VL 6
.LI
.B "output serialization"
Output for each action is collected until the action completes.
Without serialization action error messages during parallel builds
may get intermingled to the point of being useless.
.VL 6
.LI
.B AT&T
.B "nmake --serialize"
which sets the
.L CO_SERIALIZE
flag in the
.I coshell
library.
.LI
.B Lucent
Implemented with 3 new commands, one of which is a replacement wrapper for
.B nmake
itself.
.LE
.LI
.B "probe file override"
Allow a user to override the automatically generated probe files.
.VL 6
.LI
.B AT&T
.B nmake
has always searched for probe information in the
.B ../lib/probe/C/make/
directories on the
.B $PATH
environment variable.
In fact, all related files used a
.B $PATH -based
search: e.g.,
makefiles in
.B ../lib/make/ .
This was done to avoid a proliferation of
.IB foo PATH
variables
that would soon become a maintenance and portability nightmare.
To provide a local override, simply create a
.B ../lib/probe/C/make/
dir sibling to a dir on
.B $PATH ,
and place a user writable probe file in it.
Make sure the override dir is to the left of the
.B nmake
bin dir in
.B $PATH .
The probe file name is determined by running
.B "probe --key"
C make
.I "C-compiler-path" .
See
.B "probe --?override"
for more details.
.LI
.B Lucent
The user probe file is placed in a dir on
.B $PROBEPATH ,
or on
.B $VPATH ,
depending on the value of the
.B localprobe
variable.
.LE
.LI
.B "Makerules options"
.I --option=value
instead of
.I option=value
to control optional makerules behavior.
The difference is subtle but significant.
.I option
in the second (makerules variable) form can conflict
with environment and makefile variables.
It also lacks the self documentation of
.BI --?option
or
.B --man
from the
.B nmake
command line.
Makerules differences are the main point of divergence between
Lucent and AT&T
.BR nmake :
.VL 6
.LI
.B AT&T
The makerules variable form is supported for backwards compatibility.
Warnings will eventually be enabled to encourage use of the
makerules option form.
.LI
.B Lucent
Many makerules variable additions.
.LE
.LI
.B ":MAKE: ordering"
.VL 6
.LI
.B Lucent
Not implemented.
.LE
.LI
.B ":MAKE: tracing"
Emits a message when a
.B :MAKE:
directory is entered and exited.
By default the entry is listed as
.IR directory :.
.VL 6
.LI
.B AT&T
The directory name is prefixed with
.BI --recurse-enter= text
on entering a directory and
.BI --recurse-leave= text
on leaving a directory.
.LI
.B Lucent
The directory name is prefixed with the makerules variable
.B $(recurse_begin_message)
on entering a directory and
.B $(recurse_end_message)
on leaving a directory.
.LE
.LI
.B .ACTIONWRAP
.B $(.ACTIONWRAP)
is expanded instead of
.B $(@) .
.VL 6
.LI
.B AT&T
Not implemented, pending a more general solution.
.LI
.B Lucent
Its not clear how to prevent
.I all
actions from being wrapped.
.LE

.H 1 Example
The
.B nmake
.L Makefile
and
.L config.iffe
.B iffe
script for the GNU
.BR diff ,
version 2.7, 1994, are listed below.
GNU
.B diff
is a component of the
.B ast-open
package at
.xx link="/sw/download/ Software Systems Research software."
.EX
:PACKAGE: ast

VERSION                 == "2.7"
RELEASE                 == "1994-10-01"

DIFF_PROGRAM            == "diff"
DEFAULT_EDITOR_PROGRAM  == "ed"
PR_PROGRAM              == "pr"

diff :: diff.c analyze.c dir.c io.c util.c context.c ed.c ifdef.c \e
        cmpbuf.c normal.c side.c

diff3:: diff3.c \e
        LICENSE='author="Randy Smith"'

sdiff:: sdiff.c \e
        LICENSE='since=1992,author="Thomas Lord"'

:: COPYING ChangeLog NEWS INSTALL README diagmeet.note \e
        diff.info diff.info-1 diff.info-2 diff.info-3 diff.info-4 \e
        diff.texi texinfo.tex \e
        Makefile.in config.hin

:MSGFUN: fatal message \e
        perror_fatal perror_with_exit perror_with_name pfatal_with_name
.EE
The
.L :PACKAGE:
assertion causes all programs to be compiled with the
.B ast
headers and the
.L -last
library.
.L "nmake install"
will build and install the three programs
.LR diff,
.L diff3
and
.L sdiff
in
.LR "$(BINDIR)" .
The state variable
.L ==
assignments generate properly quoted
.L -D
options in the compile lines for source files that reference the variables.
The
.L :MSGFUN:
assertion declares non-standard message function names for the base rules
.L msgcat
action that reaps source message strings and generates a C locale message
catalog using
.BR msgcc (1)
and
.BR msggen (1).
.B ast
message catalogs use C locale message text as lookup keys for text in
other locales.
The
.L :MSGFUN:
assertion and the
.L msgcat
action automate the process.
.P
All of the source files include
.LR config.h ;
this is automatically generated from
.LR config.iffe ,
listed below, by the base rules
.L "%:%.iffe"
metarule.
The per-command scoped
.L LICENSE
variable assignments provide state variable information for the
.B ast
library
.BR optget (3)
self-documenting option parser (used in place of the GNU
.BR getopt_long (3).)
.EX
set     config

hdr     dirent,fcntl,limits,ndir,time,unistd,vfork
hdr     float,stdarg,stdlib,string
key     const =
lib     dup2,memchr,sigaction,strchr,tmpnam
lib     vfork = fork
sys     dir,file,ndir,wait
typ     pid_t = int

tst     note{ signal handler return type }end compile{
                #include <sys/types.h>
                #include <signal.h>
                #undef signal
                extern void (*signal())();
        }end yes{
                #define RETSIGTYPE void
        }end no{
                #define RETSIGTYPE int
        }end

tst     CLOSEDIR_VOID note{ closedir() is a void function }end nocompile{
                #include <dirent.h>
                main()
                {
                        return closedir(0);
                }
        }end

STDC_HEADERS    = ( HAVE_FLOAT_H & HAVE_STDARG_H & HAVE_STDLIB_H & HAVE_STRING_H )
HAVE_ST_BLKSIZE = mem stat.st_blksize sys/stat.h

run{
        echo "#if _PACKAGE_ast"
        echo "#include <ast_std.h>"
        echo "#endif"
        case $HAVE_VFORK_H in
        1)      echo "#include <vfork.h>" ;;
        esac
}end
.EE
.L "set config"
in this
.B iffe
script generates
.BR configure (1)
compatible
.L HAVE_*
macro names.
The
.IR name = value
statements translate from consistent
.B iffe
names to the ad-hoc
.B configure
names expected in the GNU source files.
The
.L "lib vfork = fork"
statement defines the macro
.L vfork
to be
.L fork
if
.BR vfork (2)
is not in the default libraries.

.H 1 GLOSSARY
.VL 6
.LI
.I action
An \fIaction\fP is part of an \fIassertion\fP that is specified by
indentation. In can be a shell action, an
.B nmake
action, or a scan action.
.LI
.I assertion
An \fIassertion\fP is a statement in a \fImakefile\fP that describes
a \fIrule\fP or part of a \fIrule\fP.
An assertion consists of zero or more \fItarget\fPs, an \fIoperator\fP,
zero or more \fIprerequisites\fP, and is optionally followed by
an \fIaction\fP.
.LI
.I assignment
An \fIassignment\fP is a statement in a \fImakefile\fP the assigns
a value to a \fIvariable\fP.
.LI
.I attribute
An \fIattribute\fP is a special \fIprerequisite\fP or \fItarget\fP
that is used to mark \fIrule\fPs or \fItarget\fPs.
.LI
.I "base rules"
A set of rules that are defined in a makefile that
is shipped with
.BR nmake .
This file contains contains default
rules for building software components.
These rules are implicitly included by
.BR nmake .
.LI
.I bind
\fIbinding\fP is an action taken by
.B nmake
to associate a \fIprerequisite\fP
or \fItarget\fP name with a file or other object.
.LI
.I "component directory"
A directory (and its subdirectories) controlled by a makefile.
.LI
.I "global rules"
A makefile that can be created by a project
that contains rules shared by all components
in that project.
.LI
.I "implicit prerequisite"
A \fIprerequisite\fP that is not specified in the makefile.
.LI
.I makefile
A file consisting of a set of \fIassignment\fPs and \fIassertion\fPs.
.LI
.I making
\fImaking\fP is the action taken by
.B nmake
to bring a \fItarget\fP
up to date by \fIbinding\fP all the \fIprerequisite\fPs and
running the \fIaction\fPs associated with the target if
any of the \fIprerequisite\fPs have changed.
.LI
.I metarule
a \fImetarule\fP is a type of \fIrule\fP in which the \fItarget\fP and
\fIprerequisite\fP consists of a pattern containing the wildcard
character \f5%\fP.
.LI
.I operator
An \fIoperator\fP is part of a \fIrule\fP. It can be the operator \f5:\fP,
the operator \f5::\fP,
or else a \fItarget\fP of the form \f5:\fP\fIname\fP\f5:\fP.
.LI
.I "probe information"
The set of probe variables corresponding to the current
.LR "$(CC)" .
Probe variable values are are generated by a script that is maintained by
.BR probe (1).
The information is automatically generated and updated as probe script changes
are noticed.
Probe information updates do not explicitly depend on the time stamp of the
.L "$(CC)"
executable itself, since it is usually a wrapper program for other (private)
compiler passes.
.LI
.I "probe variable"
A variable that is part of the
.I "probe information"
defined by
.BR probe (1).
.LI
.I prerequisite
A \fIprerequisite\fP is an item that needs to be checked in
order to decide whether a \fItarget\fP needs to be updated.
.LI
.I rule
A \fIrule\fP consists of a \fItarget\fP, an \fIoperator\fP,
zero or more \fIprerequisites\fP, and an \fIaction\fP.
It is generated by combining all the \fIassertion\fPs associated with a
\fItarget\fP.
.LI
.I "scan rule"
A \fIscan rule\fP rule is a type of rule that specifies how
a give source file is to be scanned for include files and
state variables.
.LI
.I "state file"
A \fIstate file\fP is a machine independent format data file that
stores information from the previous run.
It is used as the bases of deciding whether any prerequisites
of a target have changed.
.LI
.I "state variable"
A \fIstate variable\fP is a \fIvariable\fP that is scanned for in source code
and whose value is saved in the \fIstate file\fP.
.LI
.I target
A \fItarget\fP is an item that comes before an \fIoperator\fP in an \fIassertion\fP.
.LI
.I variable
A \fIvariable\fP is an item
that can be used to hold an arbitrary string.
Variable names match the RE
.L [[:alpha:]_.][[:alnum:]_.]*
or one of the special variable names
.LR [-+=%#@<>*~!?] .
.LI
.I viewpath
A \fIviewpath\fP is an ordered set of directories that are used
to search for files during the \fIbind\fP process.
.LE

.H 1 REFERENCES
.VL 6
.LI
.xx link="../publications/open-2000-1.pdf The AT&T AST OpenSource software collection",
with David Korn and Stephen North and Phong Vo,
Proceedings of the FREENIX Track 2000 Usenix Annual Technical Conference,
pp 187-195, San Diego, CA, June 2000.
.xx link="../publications/prus-1995-1.pdf Practical Reusable UNIX Software",
chapter 11,
B. Krishnamurthy, editor, Wiley, 1995.
.LI
.IR "Configuration Management" ,
with D. G. Korn and H. Rao and J. J. Snyder and K. P. Vo,
.xx link="../publications/prus-1995-1.pdf Practical Reusable UNIX Software",
chapter 3,
B. Krishnamurthy, editor, Wiley, 1995.
.LI
.IR "Libraries and File System Architecture" ,
with D. G. Korn and S. C. North and H. Rao and K. P. Vo,
.xx link="../publications/prus-1995-1.pdf Practical Reusable UNIX Software",
chapter 2,
B. Krishnamurthy, editor, Wiley, 1995.
.LI
.IR "nDFS -- The multiple Dimensional File System" ,
with D. G. Korn and H. Rao,
.IR "Configuration Management" ,
chapter 5,
W. Tichy, editor, Wiley, 1994.
.LI
.IR "Feature Based Portability" ,
with J. J. Snyder and K. P. Vo,
USENIX VHLL Symposium, Santa Fe, NM, October 1994.
.LI
.xx link="../publications/coshell-1993.pdf      The Shell as a Service",
USENIX 1993 Summer Conference Proceedings, Cincinnati, OH, June 1993.
.LI
.IR "A User-Level Replicated File System" ,
with Y. Huang, D. G. Korn and H. C. Rao,
AT&T Bell Laboratories Technical Memorandum 0112670-930414-05, April 1993,
and USENIX 1993 Summer Conference Proceedings, Cincinnati, OH, June 1993.
.LI
.IR "Tools and Techniques for Building and Testing Software Systems" ,
with J. E. Humelsine and C. H. Olson,
AT&T Technical Journal, Vol. 71 No. 6, pp. 46-61, November/December 1992.
.LI
.xx link="../publications/make-1990.pdf   A Case for make",
Software \- Practice and Experience, Vol. 20 No. S1, pp. 30-46, June 1990.
.LI
.xx link="../publications/make-1988.pdf   Product Administration through SABLE and nmake",
with S. Cichinski,
AT&T Technical Journal, Vol. 67 No. 4, pp. 59-70, July/August 1988.
.LI
.xx link="../publications/make-1985.pdf   The Fourth Generation Make",
USENIX 1985 Summer Conference Proceedings, pp. 159-174, Portland, OR, June 1985,
and UNIFORUM 1986 Winter Conference Proceedings, pp. 157-168,
Anaheim, CA, February 1986.
.LI
.xx link="http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html Recursive Make Considered Harmful",
Peter Miller, AUUGN Journal of AUUG Inc., 19(1), pp. 14-25, 1997.
.LE

Generated by  Doxygen 1.6.0   Back to index