Provided by:
smake_1.2a23-1_i386 
NAME
smake - maintain, update, and regenerate programs
SYNOPSIS
smake [ options ] [ -f makefilename ] [ target1...targetn ]
DESCRIPTION
Smake executes command sequences based on relations of modification
dates of files. The command sequences are taken from a set of rules
found in a makefile or in the set of implicit rules. The argument
target is typically a program that is to be built from the known rules.
If no -f option is present, smake looks for SMakefile then for Makefile
and then for makefile in the named order.
If no target is specified on the command line, smake uses the first
target that could be found in makefilename and that does not start with
a dot (’.’).
If a target has no explicit entry in the makefile smake tries to use
implicit rules or the .DEFAULT rule.
Unlike most other make programs, smake propagates all command line
macros to sub makes. This is a big advantage with hierarchical
makefile systems. Propagation is done in a POSIX compliant way using
the MAKEFLAGS= environment.
Unlike other make programs, smake includes a set of automake features
that allow to implement portable, layered, object oriented makefiles.
OPTIONS
-e Environment variables override macro definition in Makefile(s).
-i Ignore error codes returned by commands that are called from
rules. This is equivalent to having the special target .IGNORE:
inside a makefile.
-k Ignore errors by aborting work on the current target and
continuing the work on other targets that do not depend on the
failed target (not yet implemented).
-n Don’t make - only say what to do. This prints the commands that
would be executed on standard output. Lines with a plus sign
(’+’) will be executed in any case. Even those lines that have
an at sign (’@’) will be printed to standard output. This is
the opposite to the -s option.
-p Print the complete set of macro and target definitions on
standard output.
-q Question mode. Exit code is 0 if the target is up to date. In
all other cases, the exit code is 1. Lines with a plus sign
(’+’) will be executed in any case.
-r Turn off internal rules. Do not use the built in rules and do
not read the files ./defaults.smk and
/opt/schily/lib/defaults.smk
-s Be silent. (Do not print command lines or touch messages on
standard output before they are executed.) This is equivalent
to having the special target .IGNORE: inside a makefile.
-t Touch objects instead of executing the defined commands. This
brings a target up to date by simply setting the modification
time of the targets. Targets that do not have a command
associated are not touched. The command lines that are
associated with a target are not executed. Lines with a plus
sign (’+’) will be executed in any case.
-w Don’t print warning messages.
-W Print extra debug messages and warning messages.
-D Display Makefiles as they are read in. This allows to debug the
effective makefile when the makefiles use include statements.
-DD Display Makefiles and internal rules as they are read in. This
is the same as specifying -D but smake starts to print the
effective makefile when reading the internal definitions. If
-DDD is specified, the printout includes even the definitions of
the environment variables as make macros.
-d Print the reason why a target has to be rebuilt. Also turns off
external and internal silent flag. This special feature allows
to write makefiles that usually suppress the printing of
commands line (using a ’@’ at the start of a command line) as in
debug mode smake undoes the effect of the ’@’ character.
-dd Print additional debugging messages. This includes the messages
from the -d flag and additional messages that allow to trace the
execution of the various rules. If more ’d’ characters are
added (e.g. -dddd)theverboselevelfortracingisenhanced.
-xM Print the make file include dependency list. This options
allows to trace complex makefiles that make heavy use of the
include statement.
-xd Print extended debug messages. This is only useful, if you have
internal knowledge to smake itself and want to do heavy
debugging.
-probj Print the whole object tree. This is only useful, if you have
internal knowledge to smake itself and want to do heavy
debugging.
-help Prints a short summary of the smake options and exists.
-version
Prints the smake version number string and exists.
-posix Force smake to go into POSIX mode. This is equivalent to having
the special target .POSIX: inside a makefile. The -posix option
is not automatically propagated via MAKEFLAGS.
With this option all resulting rules and the reason for any
action is printed on the stderr stream.
-f makefilename, mf=makefilename, mf= makefilename
Specifies the Makefile.
macro=value
Set a macro. A macro definition on command line overrides any
other macro definition.
Options, command line macros and target name may be intermixed. Smake
will always first evaluate all options then all command line macros and
then will start building the targets. With smake it is not possible to
first make one target, then set a command line macro and then make the
next target with different macro values, POSIX does not specify the
behaviour in this case anyway.
BASICS
Smake maintains the dependency of a group of files by building a
dependency tree of the targets (derived files) and the files that are
the prerequisites of the targets (called the sources or the dependency
list of files). A makefile contains a description of the relations of
the targets and the prerequisites and the commands that should be
executed to make the target up to date.
foo : main.o lex.o parse.o
main.o: main.c main.h
The file foo depends on the files main.o lex.o and parse.o while main.o
depends on main.c and main.h. This example describes a project in the
C-programming language, but it is possible to maintain any project that
depends on the modification time of the related files.
Smake considers a file up to date if it has been modified after the
files it depends on (its prerequisites) and all files it depends on are
recursively up to date too. If a file does not exit, it is considered
to be out of date. The targets are processed in the order they appear
in the dependency list.
For example, if main.o is newer than foo, then it is assumed that foo
is not up to date. If main.c is newer than main.o, then it is assumed
that both, main.o and foo are not up to date.
Smake updates all targets based on rules. A rule specifies a target
and its prerequisites and defines a set of commands that allow to
create an up to date target from its prerequisites.
If the target and its prerequisites are named explicitely, the rule is
called an explicit rule. If the target and its prerequisites are named
in an abstract way, the rule is called an implicit rule.
If smake is called to update a target, it first checks if an explicit
rule for this target can be found. If there is no explicit rule for
this target, then smake looks for an implicit rule. It checks the
following methods of specifying an implicit rule until a suitable rule
is found. Each method is described in section Makefile Format below
XXX Implicit Rules ???.
· Pattern matching rules from a user supplied makefile.
· Suffix rules, either from a user supplied makefile or from the
set of builtin rules.
· Simple suffix rules, either from a user supplied makefile or
from the set of builtin rules.
· SCCS retrieval. If smake finds a more recent SCCS history file,
it tries to retrieve the most recent version from the SCCS
history. See the description of the .SCCS_GET: special target.
· The rule from the .DEFAULT: target entry, if such an entry
exists in a makefile.
A limited set of builtin rules is compiled into smake. A more complete
set is read from the file ./defaults.smk or
/opt/schily/lib/defaults.smk.
Makefile Format
Smake reads its rules from a file named SMakefile, Makefile or makefile
in the current directory. If a different makefile is specified with
the -f option, smake reads from this file. In case that no makefile
was specified with the -f option, it is not an error if no makefile
exists. In this case smake only uses the built in rules. The term
makefile is used for any user supplied file that contains rules for the
make utility.
A makefile contains rules, macro definitions, special make directives
and comments. A rule may either be a target rule (explicit rule) or an
implicit rule. Smake itself contains a number of built in implicit
rules which are not used if the -r option is used. The user specified
makefile defines additional explicit and implicit rules and macros. If
a macro is defined more than once, the last definition is used. If a
target rule is defined more than once, the dependency list is the sum
of all dependency lists and the set of commands is the set of commands
from the last specification. A back slash (’\’) at the end of a line
indicates that this line is to be continued on the next line. XXX An
escaped newline is replaced by a single space character XXX and the
white space at the beginning of the next line is removed. XXX A comment
starts with a hash mark (’#’) and ends if an un-escaped new line is
found.
Command Execution
Target rules
A target rule looks this way:
target ... : [dependency] ... [; command] ...
[<tab> command]
...
The first line may not start with a TAB character. It starts with a
target name or a white space separated list of target names, in both
cases followed by a target separator (’:’). The colon may be followed
by a dependency name or a white space separated list of dependency
names. The dependency list may be followed by a semicolon (’;’) and a
Bourne shell command. There may be additional lines with Bourne shell
commands, all starting with a TAB. The first line that does not start
with a TAB starts another definition.
Bourne shell commands may be continued over more than one line if the
new line is escaped with a back slash. The next line must also start
with a TAB character.
Make directives
export XXX lkfglsdfg
include
XXX lkfglsdfg
-include
XXX lkfglsdfg
readonly
XXX sdfsdfsda
SEARCHING RULES FOR FILES
In many cases, it is desirable to hold object files in a special
directory which is different from the directory where the source files
are located. For this reason, smake allows to specify a directory
where all targets are placed that are a result of an implicit rule.
Add
.OBJDIR: object_directory
to the makefile to activate this smake feature. If a makefile uses
this feature, it must either explicitely use the right file names
(including the object directory) or use dynamic macros that are
automatically updated to include the path of the object directory. If
smake uses file name searching, the dynamic macros $<, $0, $n, $r1, $^,
and $? are updated to reflect the actual path of the source or object
directory.
A line of the form:
.SEARCHLIST: source_directory_1 object_directory_1 ...
that contains pairs of source and corresponding object directory names,
will cause smake not only to search for files in the current directory
and in the directory which is pointed to by .OBJDIR, but also in the
directories from .SEARCHLIST. Smake first looks in the current
directory, then in the directory pointed to by .OBJDIR and then in the
directories from .SEARCHLIST.
If a source could be found in a specific source directory of the list
of source and object directories, the targets will only be looked for
in the corresponding object directory. A result of a source, which is
found in any of the source-directories of the .SEARCHLIST is placed
into the corresponding object-directory.
A line in the form:
.OBJSEARCH: value
Where value may be one of src, obj, all. causes smake to look for
left-hand-sides of rules in only the source-directories, the object-
directories or both. The default value for .OBJSEARCH is: all. That
causes smake to search for results only in object-directories and
source-directories.
If no .SEARCHLIST: target exists, but a VPATH= macro is found, smake
transforms the content of the VPATH= macro into a form suitable for
.SEARCHLIST:. This is done by putting each VPATH= entry twice into the
.SEARCHLIST. Please report problems with this solution.
VARIABLE SUBSTITUTION
Any variable defined by a line in the form:
varname= val
may referenced by either: $(varname) or ${varname}.
Special Targets
.DEFAULT:
If a target is considered to be out of date and no other rule
applies to this target, smake executes the commands from this
special target. The .DEFAULT target may not have a dependency
list.
.DONE: If this special target is present, smake executes the commands
after all targets have been processed. The .DONE target is also
executed if a failure occurs and no .FAILED target is present.
The .DONE target may not have a dependency list.
.FAILED:
If this special target is present and an error occurred, smake
executes the commands instead of the the commands of the .DONE
target after all targets have been processed. The .FAILED
target may not have a dependency list.
.GET_POSIX
Reserved for future use.
.IGNORE:
Ignore errors. If this special target is present, smake behaves
as if it was called with the -i flag.
POSIX requires that .IGNORE only applies to some targets if they
are in the list of dependencies of the .IGNORE target. Smake
currently does not implement this POSIX behaviour.
.INCLUDEFAILED:
This special target implements automake features for object
oriented layered makefiles. If this target is present, smake
executes the commands for this target if a make file could not
be included and there was no rule that could create the the
missing make include file. The .INCLUDEFAILED target may not
have a dependency list.
.INIT: If this target is present, the target and its dependencies are
built before any other target is made.
.KEEP_STATE
Reserved by SunPRO make. Don’t use this target to avoid problems
with the SCHILY (Sing) makefile system.
.KEEP_STATE_FILE
Reserved by SunPRO make. Don’t use this target to avoid problems
with the SCHILY (Sing) makefile system.
.MAKE_VERSION
Reserved for future use. Future versions of smake may implement
this special target in a way similar to SunPRO make.
A special target of the form:
.MAKE_VERSION: smake-number
forces to check the version of smake. If the version of smake
differs from the version in the dependency list, smake issues a
warning message. The actual version of smake is smake-1.0
.NO_PARALLEL
Reserved for future use.
.OBJDIR:
If this special target is present, smake assumes that all files
that have been created by a rule should be placed in a special
directory called the object directory. The object directory is
the only member of the dependency list of the .OBJDIR target.
Smake moves the targets automatically into that directory.
Automatic macros like $^, $?, $r1 are automatically modified in
a way that allows transparent use of the object directory. If
.OBJDIR is not specified, it is assumed to be the current
directory ’.’.
.OBJSEARCH:
This target may hold one of three predefined values: src, obj
and all. It defines where objects (targets of a rule) are
searched for. The default for .OBJSEARCH is to look for targets
in both (source and object) directories or directory lists. See
also .SEARCHLIST for a description of the src and obj
directories.
.PARALLEL
Reserved for future use.
.POSIX:
Reserved for future use.
.PRECIOUS:
This macro holds a list of targets that should not be removed
while they are built if sake receives a signal.
.PHONY:
This macro holds a list of targets that should not be checked
against existing files. A target that is marked .PHONY will
always considered to be out of date. If smake receives a signal,
targets marked as .PHONY are not removed.
.SCCS_GET:
Reserved for future use.
.SCCS_GET_POSIX
Reserved for future use.
.SEARCHLIST:
.SEARCHLIST is a list of alternate source and object directories
where smake should look for targets. This macro may be used as
an extended replacement of the VPATH= macro of other make
programs. The macro .SEARCHLIST holds a list of srcdir /
objdir pairs. The complete internal list is build from ’.’
.OBJDIR and the content of .SEARCHLIST.
.SILENT:
.SUFFIXES:
Reserved for future use.
.SYM_LINK_TO
Reserved for future use.
.WAIT Reserved for future use.
Special Macros
MAKE This macro contains a path name that is sufficient to
recursively call the same make program again (either that last
path component or the full path name of the make program). Note
that this may differ from the name that was used on the command
line if the name that was used on the command line would not
allow to call the same make program from a different directory
using this name. For this reason $(MAKE) may not be used to
check for a specific make program. Use $(MAKE_NAME) instead.
MAKEFLAGS
This macro contains the command line flags and the command line
macros smake is called with. The MAKEFLAGS macro is exported
into the environment to allow automatic propagation of make
flags and command line macros to sub make programs. The content
of this macro is POSIX compliant.
If there were no command line flags or command line macros, the
MAKEFLAGS macro is empty.
If there were only command line flags, the MAKEFLAGS macro
contains a concatenation of the single char versions of the
flags. A hyphen is the first char, so MAKEFLAGS would be
suitable as a command line flag in this case. A typical content
may look this way:
-id.
If there were only command line macros, the MAKEFLAGS macro
contains a concatenation of the macro specifications. The
different macro specifications are separated by a space. Any
occurrence of a space or a back slash inside a macro
specification is escaped by a back slash. A typical content may
look this way:
CC=gcc COPTX=-DTEST\ -DDEBUG.
If both command line flags and command line macros are used, the
flag part is made as if there were only flags and the macro part
is made as if there were only macros. The separator between the
flag part and the macro part is a space, two hyphens and a
space. A typical content may look this way:
-id -- CC=gcc COPTX=-DTEST\ -DDEBUG.
As the MAKEFLAGS notation of the command line macros uses a
special escape notation to allow to propagate any possible
command line macro, it is not possible to call:
make $(MAKEFLAGS) from a make file.
MAKE_MACS
This macro contains the complete set of command line macros and
the macros read from the MAKEFLAGS environment. The content is
the same as the last part of the MAKEFLAGS macro which holds the
macro part. The MAKE_MACS macro is exported into the
environment.
MAKE_FLAGS
This macro contains the command line flags smake is called with.
The content is the same as the content of the MAKEFLAGS macro
except that no command line macros are added. The MAKE_FLAGS
macro is exported into the environment.
MAKE_ARCH
This macro is set up by smake as part of the automake features
of smake. It contains the processor architecture of the current
machine (e.g. mc68020, sparc, pentium).
MAKE_BRAND
This macro is set up by smake as part of the automake features
of smake. It contains the brand of the current machine (e.g.
Sun_Microsystems).
MAKE_HOST
This macro is set up by smake as part of the automake features
of smake. It contains the host name of the current machine
(e.g. duffy, sherwood, ghost).
MAKE_MACH
This macro is set up by smake as part of the automake features
of smake. It contains the kernel architecture of the current
machine (e.g. sun3, sun4c, sun4m, sun4u).
MAKE_MODEL
This macro is set up by smake as part of the automake features
of smake. It contains the model name of the current machine
(e.g. SUNW,SPARCstation-20).
MAKE_M_ARCH
This macro is set up by smake as part of the automake features
of smake. It contains the machine architecture of the current
machine (e.g. sun3, sun4).
MAKE_NAME
This macro is set up by smake as part of the automake features
of smake. It contains the official name of the make program -
in our case smake.
MAKE_OS
This macro is set up by smake as part of the automake features
of smake. It contains the operating system name of the current
machine (e.g. sunos, linux, dgux).
MAKE_OSDEFS
This macro is set up by smake as part of the automake features
of smake. It contains operating system specific defines for the
compiler (e.g. -D__SVR4).
MAKE_OSREL
This macro is set up by smake as part of the automake features
of smake. It contains the operating system release name of the
current machine (e.g. 5.5, 4.1.1).
MAKE_OSVERSION
This macro is set up by smake as part of the automake features
of smake. It contains the operating system version of the
current machine (e.g. generic).
MAKE_SERIAL
This macro is set up by smake as part of the automake features
of smake. It contains the serial number of the current machine
(e.g. 1920098175).
MAKE_VERSION
This macro contains the smake version number string.
VPATH This macro implements some object search functionality as found
in other UNIX make programs. In smake this functionality is
implemented using the .SEARCHLIST: special target, see chapter
SEARCHING RULES FOR FILES for more information.
Dynamic Macros
There are several internal macros that are updated dynamically. Except
$O, they cannot be overwritten. Using them in explicit rules makes the
makefile more consistent as the file names do not have to be typed in a
second time. Using them in implicit rules is the only way to make
implicit rules work as the actual file name cannot be coded into an
implicit rule.
If smake uses file name searching, the dynamic macros $<, $0, $n, $r1,
$^, and $? are updated to reflect the actual path of the source or
object directory.
The dynamic macros are:
$O expands to the value of .OBJDIR. If .OBJDIR is not defined, $O
expands to ’.’.
$@ expands to the path name of the current target. It is expanded
for both explicit and implicit rules.
$* expands to the path base name of the current target (the name of
the current target with the suffix stripped off). It is
expanded for both explicit and implicit rules. POSIX requires
that this macro is expanded at least for implicit rules.
$< expands to the path name of implicit source made in this step.
It is expanded for implicit rules only. The existence of this
macro is required by POSIX.
$0 expands to the path name of implicit source made in this step.
It is expanded for implicit rules only. This macro is available
with smake only. It is made available to make the behaviour more
orthogonal.
$1 $2 $3 ...
expands to the path name of the nth file in the dependency list.
It is expanded for explicit rules only.
$rn expands to the path names of all files in the dependency list
starting with the nth. It is valid to specify $r0. It is
expanded for both explicit and implicit rules. The 0th entry is
available only with implicit rules, the other entries ae
available only with explicit rules.
$^ expands to the path names of all files in the dependency list.
It is identical to $r1. It is expanded for both explicit rules
only.
$? expands to the path names of all files outdated dependencies for
this target. It is expanded for explicit rules only. POSIX
requires that this macro is expanded for both explicit and
implicit rules.
The following example shows how dynamic macros may be used together
with file searching rules:
foo : main.o lex.o parse.o
$(CC) -o $@ $^
may expand to:
cc -o foo OBJ/main.o parser/OBJ/lex.o parser/OBJ/parse.o
IMPLICIT RULES
Pattern Matching Rules
Pattern matching rules have first been found in Sun’s SunPRO make.
They are now also inplemented in GNU make and smake.
A pattern matching rule looks this way:
tp%ts: dp%ds
target_suffix : dependency_1_suffix ...
<tab> dependency_command
...
XXXXX XXXXX falsch !!!
Suffix Rules
Suffix rules are the POSIX way of spefifying implicit dependencies.
A Suffix rule looks this way:
DsTs:
<tab> dependency_command
...
XXXXX falsch !!!
Simple Suffix Rules
Simple suffix rules are specific to smake.
A simple suffix rule looks this way:
target_suffix : dependency_1_suffix ...
<tab> dependency_1_command
...
The first line may not start with a TAB character. It starts with the
target suffix or "" if no target suffix exists. The target suffix is
followed by the target separator (’:’) and one or more dependency
suffixes which are also written as "" if no dependency suffix exists.
The first line is followed by exactly the same number of Bourne shell
command lines (each starting with a TAB) as there were dependency
suffix specification in the first line. Each of the Bourne shell
command lines correspond to one of the dependency suffixes in the same
order.
When smake looks for a possible source for a target with a specific
suffix, the dependency suffixes are tried out in the order they appear
in the first line of the suffix rule. If a source is found, the
corresponding command line is executed.
There may only one simple suffix rule per target suffix. All suffixes
except the empty suffix ("") must start with a dot (’.’).
The following example shows how a simple suffix rule for creating a
zero suffix executable from a .o file may look:
"": .o
$(CC) -o $@ $<
A simple suffix rule that describes how to create a .o file from the
possible .c and .s sources may look this way:
.o: .c .s
$(CC) -c $<
$(AS) -o $*.o $<
If smake is going to update foo.c using simple suffix rules, it will
first look for a file foo.c and then for a file foo.s. If the file
foo.c can be found the first command line ($(CC) -c $<) is executed, if
the file foo.s can be found the second command line ($(AS) -o $*.o $<)
is executed. Which command is executed depends on which source file
exists.
DEFAULT RULES
Changing the implicit rules allows to change the default behaviour of
smake.
The current default implicit rules are using the simple suffix rule
notation:
FC= f77
RC= f77
PC= pc
AS= as
CC= cc
LEX= lex
YACCR= yacc -r
YACC= yacc
ROFF= nroff
RFLAGS= -ms
.o: .c .s .l
$(CC) -c $(CFLAGS) $0
$(AS) -o $*.o $0
$(LEX) $(LFLAGS) $0;$(CC) -c $(CFLAGS) lex.yy.c;rm lex.yy.c;mv lex.yy.o $@
.c: .y
$(YACC) $(YFLAGS) $0;mv y.tab.c $@
"": .o .sc
$(CC) -o $* $0
$(ROFF) $(RFLAGS) $0 > $@
COMMAND EXECUTION
All commands are executed by the standard shell (/bin/sh). They may
use all constructs that are permitted for a POSIX shell as long as the
local shell supports them.
ENVIRONMENT
FILES
SMakefile
Makefile
makefile
Smake first looks for SMakefile then for Makefile and then for
makefile in the current directory to find a list of rules to be
used to resolve the targets.
defaults.smk
If smake finds this file in the current directory, then the
implicit rules are read in from this file.
/opt/schily/lib/defaults.smk
If the file defaults.smk could not be found, then smake tries to
read the implicit rules from this file. If this file cannot be
found too, then smake uses the rules compiled into smake.
SEE ALSO
sh(1), makefiles(4), makerules(4)
NOTES
The old schily (SING) makefile system (until late 1999) did only define
simple suffix rules. The current version of smake added support for
pattern matching rules and POSIX suffix rules. These rules are
considered to be rated with higher preference than simple suffix rules.
If build in suffix rules can be found, current smake versions will not
work correctly with old makefile systems. To use current smake
versions with old makefile systems, call smake with the -r flag to
disable build in POSIX suffix rules. Newer makefile system version
include pattern matching rules that will be searched before the POSIX
suffix rules.
A new shell is run for each command line. If you want to run more
complicated shell scripts, you need to escape the end of line with a
backslash to keep all commands on one virtual shell command line.
Smake will in the near future be as POSIX compliant as possible.
POSIX does not cover everything that is needed to write portable
makefiles suitable to compile large portable projects. Even simple
things like macro+=value are not covered by POSIX. Note that adding
something to a macro definition is supported by all known make
implementation since ~ 1980. In addition, it is most unlikely that
different make implementations although POSIX compliant, are as
compatible enough to maintain large projects. For these reasons, it
seems to be better to have a portable make implementation like smake.
BUGS
Pattern matching rules, POSIX suffix rules and the .DEFAULT target have
recently been implemented. There may be bugs in the code. SCCS
retrieval is not yet implemented.
Built in library handling is not implemented.
There are currently no other known bugs, but as smake since 1994 has
mainly been used with the the SCHILY (Sing) makefile system, there may
be bugs with other makefiles.
In any case, smake is the best choice when compiling projects that are
using the SCHILY (Sing) makefile system.
AUTHOR
Joerg Schilling
Seestr. 110
D-13353 Berlin
Germany
Mail bugs and suggestions to:
joerg@schily.isdn.cs.tu-berlin.de or js@cs.tu-berlin.de or
schilling@fokus.gmd.de