SMAKE(1) Schily´s USER COMMANDS SMAKE(1)NAMEsmake - maintain, update, and regenerate programs
SYNOPSISsmake [ 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 tar‐
get 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 in POSIX mode, smake
looks for makefile, Makefile and then for SMakefile.
If no target is specified on the command line, smake uses the first
regular target that could be found in makefilename and that does not
start with a dot ('.') letter combination.
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 make‐
file 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-C dir Change the working directory to dir before starting work.
-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
without dependencies inside a makefile.
-k Ignore errors by aborting work on the current target and contin‐
uing the work on other targets that do not depend on the failed
target.
-N Continue if a named dependency does not exist and no related
source could be found. Smake by default aborts on this condi‐
tion, but it seems that traditional UNIX make programs ignore
this condition for unknown reason.
-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. If a com‐
mand line contains the macro $(MAKE) or ${MAKE} this command
line is executed even if there is no plus sign ('+').
-p Print the complete set of macro and target definitions on stan‐
dard 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 Undo the effect of the -k option and terminate smake if an error
occurs while updating targets.
-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 .SILENT without dependencies 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 instead of performing the their rules.
Warning: This can be dangerous when files are maintained by more
than one person. 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.
-WW Print even more 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 com‐
mands 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) the verbose level for tracing is enhanced.
-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 debug‐
ging.
-probj Print the whole object tree. This is only useful, if you have
internal knowledge to smake itself and want to do heavy debug‐
ging.
-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.
See the description of the special target .POSIX for more infor‐
mation.
-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
behavior in this case anyway.
OPERANDS
The following operands are supported:
target any number of target names. The targets are build in the order
of occurence.
macro=value
A macro definition. Macro definitions from the command line
overwrite regular macro definitions in makefiles or taken from
the environment.
All macro definitions are evaluated before any target it build.
BASICS
Smake maintains the dependency of a group of files by building a depen‐
dency 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 cre‐
ate 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 or an inference
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 fol‐
lowing methods of specifying an implicit rule until a suitable rule is
found. Each method is described in section Makefile Format below or in
the section 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 his‐
tory. 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 built in rules is compiled into smake. A more com‐
plete 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 and checks for the files in the named order.
If in POSIX mode, smake looks for makefile, Makefile and then for
SMakefile. 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 or loads 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.
An escaped newline is replaced by a single space character and the
white space at the beginning of the next line is removed. A comment
starts with a hash mark ('#') and ends if an un-escaped new line is
found.
Command Execution
Command lines associated with rules are sequentially executed line by
line in an own process or shell. All commands may use constructs sup‐
ported by the standard shell (/bin/sh). POSIX shell constructs are
permitted as long as the local shell supports them. Command lines may
have prefixes that are interpreted by smake before the rest of the com‐
mand line is executed or passed to the shell. All characters from the
list below that immediately follow the TAB character are interpreted by
smake. The first non-blank character that is not from the list below
is the first character passed to the shell. The following prefixes are
implemented:
- If the character '-' is amongst the prefix characters or of the
-i option has been specified or the special target .IGNORE has
been specified with no dependencies or with the current target
in the list of dependencies, the exit code from the command line
is ignored.
+ If the character '+' is amongst the prefix characters, the com‐
mand line is executed even if one of the options -n, -q or -t
was specified.
@ If the character '@' is amongst the prefix characters or of the
-s option has been specified or the special target .SILENT has
been specified with no dependencies or with the current target
in the list of dependencies, the command line is not printed
before it is executed.
? Reserved for future use (currently ignored).
! Reserved for future use (currently ignored).
Typical UNIX systems are fast with calling the shell. Some operating
systems (like e.g. win32) however are slow with creating processes. As
calling a command via the shell results in creating an additional
process, command execution via the shell causes unneeded overhead for
simple commands. To speed up command execution, smake tries to avoid
calling commands via the shell when no shell meta character appears on
the commandline. As commandlines used in makefiles frequently look
like:
@echo message; cc ...
smake avoids to call a shell in such cases by executing simple echo
commands inline in case they are at the beginning of a command. A sim‐
ple echo command is a command without I/O redirection and without shell
variable expansion.
If the environment FORCE_SHELL is present or the special target
.FORCE_SHELL: has been defined, smake does not try to optimize command
execution and calls all commands via the shell. If the SHELL special
macro is used to define an alternate shell that is based on a different
set of shell meta characters than the meta characters used by the POSIX
shell:
# | = ^ ( ) ; & < > * ? [ ] : $ ` ' " \ \n
it is recommended to define the special target .FORCE_SHELL: in addi‐
tion.
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 colon as a target separator (':') or by a double
colon ('::'). The colon may be followed by a dependency name or a
white space separated list of dependency names. The double colon
allows to specify alternate dependency lists and commands for the same
target. 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 macro ...
The list of macros that follows the export directive is exported
in the list of environment variables. If an environment vari‐
able with the same name already exists, it's value is replaced
by the current value of the related make macro. An empty list
of macro names is not considered an error. If the PATH macro is
in the list of parameters, the path search of the current smake
process is also affected. If the SHELL macro is in the list of
parameters, it is ignored and the previous SHELL environment is
kept.
include filename ...
Reading and parsing makefiles is temporarily continued with the
list of the file name parameters to the include directive. If
one or more file names from the parameter list contains make
macro expressions, the macro expressions are evaluated before
the file names are used. A single make macro may contain a list
of include file names. If smake knows rules to make the files
to include, smake will evaluate the related rules before doing
the include. Include directives may be nested as long as there
are unsued file descriptors. An empty list of filenames is not
considered an error. If one or more files from the parameter
list do not exist, smake aborts.
-include filename ...
The -include directive is implemented similar to the include
directive, except that a nonexistent file is not considered to
be an error.
readonly macro ...
Mark the list of macros in the parameter list as readonly. This
prevents further modification of the content of the related
macros. An empty list of macro names is not considered an
error.
unexport macro ...
The list of macros that follows the unexport directive is
removed from the list of environment variables. An empty list
of macro names is not considered an error. If the PATH macro is
in the list of parameters, the path search of the current smake
process is also affected. If the SHELL macro is in the list of
parameters, it is ignored and the previous SHELL environment is
kept.
Automake Features
Smake implements automake features that help to write highly portable
makefile systems. The automake features are implemented with a set of
special purpose macros and by special rules that help to extend the
functionality and automated adaptivity of smake.
Automake special purpose macros
The special purpose macros that have names that match MAKE_* (see sec‐
tion Special Macros) are part of the automake features of smake. The
related special macros are set up by smake to contain values that have
been retrieved from the results of the uname(2), sysinfo(2) or
sysctl(2) system calls. The values for these macros may however be
overwritten from a makefile or from a command line macro definition.
Automake special targets
The special target .INCLUDE_FAILED allows to define a rule that is
evaluated in case that an include files does not exist and could not be
made from other rules. As the asociated command for this target is
typically a shell script, the shell script can be written to create
fall back rules in a platform independent way.
Search Rules For Files
In many cases, it is desirable to hold object files in a special direc‐
tory 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 in case they 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 auto‐
matically 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 direc‐
tory, 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 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.
Macros
Macro Definitions
Macros are defined by a line in the form:
macroname= value
The value assigned to the macro contains all characters after the equal
sign up to a comment character ('#') or an unescaped newline. Any blank
characters that directly follow the equal sign are ignored.
An alternate macro definitions use the form:
macroname += value
to append value to the current definition for macroname. Note that
there needs to be white space before the '+=' as smake allows macro
names like C++.
A macro definition that uses the form:
macroname:= value
will evaluate the right side of the assignment when the line is read by
the parser. Note that SunPro make uses := for a different incompatible
purpose. A makefile that uses := is non-portable.
A macro definition that uses the form:
macroname:sh= command
will call command and define the macro value to be the output of com‐
mand when the line is read by the parser.
Macro References
Macros may be referenced by either: $(macroname) or ${macroname}. The
parentheses or braces are optional for a macro with a single character
name.
Macro definitions and macro references can appear anywhere in the make‐
file. Macro references are expanded under the following circumstances:
· Macros in target lines are evaluated when the target line is
read by the parser.
· Macros in command lines for rules are evaluated when the command
is executed.
· Macros in the string before ':', '::', '=' or '+=' (names for
target or macro definitions) are evaluated when the target line
is read by the parser.
· Macro references after the equal sign in a macro definition are
not evaluated until the defined macro itself is used in a rule
or a command or to the left of the equal sign from a macro defi‐
nition.
Macro Substitution
Macro references may be used to substitute macro values. There are
different methods for macro substitution.
Suffix Replacement Macro References
A macro reference in the following form:
$(name:subst1=subst2)
is used to replace the suffix or word subst1 in the value of the macro
name by subst2. Words are separated by space or tab characters.
Pattern Replacement Macro References
A macro reference in the following form:
$(name:op%os=np%ns)
is used to replace prefixes and suffixes in words. In this case, op is
the old prefix, os is the old suffix, np is the new prefix and ns is
the new suffix. The strings op, os, np and ns may all be empty
strings. The pattern % matches a string of zero or more characters.
The matched pattern is carried forward to the replacement target. For
example:
OBJECT=foo.o
SCCS_HISTFILE=$(OBJECT:%.o=SCCS/s.%.c)
replaces foo.o by SCCS/s.foo.c when the macro $(SCCS_HISTFILE) is ref‐
erenced.
Shell Replacement Macro References
A macro reference in the following form:
$(name:sh)
will interpret the content of the macro name as a shell command line,
call the shell with the content of the macro and return the output of
the called command.
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 tar‐
get may not have a dependency list.
.FORCE_SHELL:
If this special target is present, smake executes all commands
via the shell instead of trying to optimize command execution
for simple commands.
.GET_POSIX:
Reserved for future use.
.IGNORE:
Ignore errors. When this special target is present and has no
dependencies, smake will ignore errors from commands. Specify‐
ing .IGNORE: without dependencies is equivalent to using the -i
option. If .IGNORE: has dependencies and the current target is
in the list of dependencies of .IGNORE: the exit code for the
related commands is ignored.
.INCLUDE_FAILED:
This special target implements automake features for object ori‐
ented layered makefiles. If this target is present, smake exe‐
cutes the commands for this target in case that a make file
could not be included and there was no other explicit or
implicit rule that did create the the missing make include file.
The .INCLUDE_FAILED target may not have a dependency list. When
the commands for the target .INCLUDE_FAILED are called, the
dependency list of the special target is set up to the include
file name. The commands for the target .INCLUDE_FAILED are
called for both, the include and the -include directive. If the
commands for the .INCLUDE_FAILED target cannot create a file
that is going to be included, smake will fail in case that the
include directive was used.
.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.
.NO_WARN:
If this special target is present and has a dependency list,
special warnings may be disabled depending on the names used in
the pseudo dependency list.
If .NO_WARN: does not have any dependencies, the list of warning
exceptions is cleared.
The following pseudo dependencies are implemented:
:= Suppress warnings about nonportable ':=' macro assign‐
ments.
$$* Suppress warnings for using the dynamic macro '$*' in
explicit rules.
$$< Suppress warnings for using the dynamic macro '$<' in
explicit rules.
.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 tar‐
gets in both (source and object) directories or directory lists.
See also .SEARCHLIST for a description of the src and obj direc‐
tories.
.PARALLEL:
Reserved for future use.
.POSIX:
If this special target is found, POSIX mode is enabled.
With this option the verbose command lines written to the stdout
stream are prefixed by a TAB character instead of three dots
(...). I POSIX mode, smake also calls commands via /bin/sh -c
'cmd' instead of /bin/sh -ce 'cmd'. This causes smake not to
stop at failing sub commands in complex commands. If the .POSIX:
special target is used, it is highly recommended to also specify
MAKE_SHELL_FLAG=-ce to make sure that the make process still
stops at failed commands.
.PRECIOUS:
This macro holds a list of targets that should not be removed
while they are built if smake receives a signal. If the list is
empty, this applies to all targets.
.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. If smake is called
with the -t (touch) option, the targets marked as .PHONY are not
touched.
.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 pro‐
grams. The macro .SEARCHLIST holds a list of srcdir / objdir
pairs. The complete internal list is build from '.' .OBJDIR
and the content of .SEARCHLIST.
.SILENT:
Run silently. When this special target is present and has no
dependencies, smake will not echo commands before executing
them. Specifying .SILENT: without dependencies is equivalent to
using the -s option. If .SILENT: has dependencies and the cur‐
rent target is in the list of dependencies of .SILENT: the
related commands are not echoed before they are executed.
.SPACE_IN_NAMES:
If this target is present and has a dependency list, escaped
spaces may occur in object and dependency names. If
.SPACE_IN_NAMES: is not followed by any dependency, the previous
dependencies are cleared and make file parsing is done again in
a POSIX compliant way. The following code fragment allows to
use non standard space handling for one target only:
.SPACE_IN_NAMES: true
target\ with\ spaces: dependency\ with\ spaces
command list
.SPACE_IN_NAMES:
.SSUFFIX_RULES:
If this special macro is present with no dependencies, all cur‐
rent Simple Suffix Rules are cleared.
.SUFFIXES:
Dependencies of .SUFFIXES are appended to the list of known suf‐
fixes and are used in conjunction with the suffix rules (see
Suffix Rules). If .SUFFIXES does not have any dependencies, the
list of known suffixes is cleared. If the list of .SUFFIXES was
cleared, no implicit suffix rule search is done.
.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 recur‐
sively 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. If a command
line contains this macro, this command line is executed even if
there is no plus sign ('+').
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 con‐
tains 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 con‐
tains a concatenation of the macro specifications. The differ‐
ent macro specifications are separated by a space. Any occur‐
rence 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 spe‐
cial 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 environ‐
ment.
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_HOST_OS
This macro is set up by smake as part of the automake features
of smake. It contains the host OS name from uname -Hs of the
current machine in case that there is a layered OS like Cygwin
(e.g. windows).
MAKE_HOST_OSREL
This macro is set up by smake as part of the automake features
of smake. It contains the host OS release from uname -Hr of the
current machine in case that there is a layered OS like Cygwin
(e.g. 5.1).
MAKE_HOST_OSVERSION
This macro is set up by smake as part of the automake features
of smake. It contains the host OS version from uname -Hv of the
current machine in case that there is a layered OS like Cygwin
(e.g. sp2).
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 cur‐
rent 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_SHELL_FLAG
This macro contains the shell flags used when calling commands
from smake. The default value is -ce, When smake in in POSIX
mode, the default value is -c. The MAKE_SHELL_FLAG macro allows
to overwrite the default behavior.
MAKE_SHELL_IFLAG
This macro contains the shell flags used when calling commands
from smake-i. The default value is -c. The MAKE_SHELL_IFLAG
macro allows to overwrite the default behavior.
MAKE_VERSION
This macro contains the smake version number string.
NUMBER_SIGN
This macro is predefined to contain the number sign ('#') that
is used as the make comment start character and for this reason
cannot be appear in non comment parts of regular makefiles.
SHELL The SHELL macro is neither imported nor exported from/to the
environment. If it is set from within a makefile or from the
commandline, the value is used as the name of an alternate shell
to execute commands. Makefiles that set SHELL= should be used
very carefully as not all platforms support all shells.
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
Search 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 '.'. If $O has been overwritten, it may no longer be
used as a reliable alias for .OBJDIR.
$@ 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 behavior 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 avail‐
able 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
If there is no explicit target rule for a specific target, smake tries
to find a matching implicit rule. There are three different types of
implicit rules. Pattern Matching Rules are searched first. If no
matching pattern matching rule could be found, the Suffix Rules are
checked and if there was no matching suffix rule, the Simple Suffix
Rules are checked.
Commands defined for implicit rules of any type typically make use of
the dynamic macros $@, $* and $< as placeholders for target and depen‐
dency file names.
Pattern Matching Rules
Pattern matching rules have been introduced by SunPRO make on SunOS-3.x
in 1986. They are now also implemented in smake. Pattern matching
rules are searched in the same order as they appear in the makefile.
A pattern matching rule looks this way:
tp%ts: dp%ds
<tab> command
...
In this rule, tp is the target prefix, ts is the target suffix, dp is
the dependency prefix and ds is the dependency suffix. Any of the
parts may be a null string. The % part of the strings is the base name
that matches zero or more characters in the target name. Whenever
smake encounters a match with a target pattern of a pattern matching
rule, it uses the matching base name to construct dependency names. If
the target is out of date relative to the dependency, smake uses the
commands from the pattern matching rule to build or rebuild the target.
A rule in the form:
tp%ts:
<tab> command
...
is permitted.
Suffix Rules
Suffix rules are the POSIX way of spefifying implicit dependencies.
Suffix rules are searched when no pattern matching rule applies. If
the special target .SUFFIXES: was cleared or is empty, smake does not
check suffix rules. If .SUFFIXES: defines a list of suffixes, the cur‐
rent target file name is checked against this list. If there is a
match, the list of suffix rules is checked against the target suffix
and a dependency suffix that is also in the .SUFFIXES: list. The search
order is derived from the order of suffixes in the suffix list while
matching dependency suffixes. A suffix does not need to begin with a
'.' to be recognized.
A Double Suffix rule looks this way:
DsTs:
<tab> dependency_command
...
Ds is the dependency suffix and Ts is the target suffix. They are used
when both target file name and dependency file name have a suffix.
Double Suffix rules are searched before Single Suffix rules are
checked.
A Single Suffix rule looks this way:
Ds:
<tab> dependency_command
...
Ds is the dependency suffix. Single Suffix rules are used when the
target file name does not have a suffix.
Simple Suffix Rules
Simple suffix rules have the lowest preference when looking for
implicit 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 suf‐
fixes which are also written as "" if no dependency suffix exists. The
first line is followed by exactly the same number of Bourne shell com‐
mand lines (each starting with a TAB) as there were dependency suffix
specifications in the right side of 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 corre‐
sponding 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 IMPLICIT RULES
Changing the implicit rules allows to change the default behavior of
smake.
Default Simple Suffix Rules
The current default implicit rules are using the simple suffix rule
notation are compiled into smake:
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 > $@
If smake reads a file defaults.smk with default implicit rules, the
compiled in rules are disabled.
ENVIRONMENT VARIABLES
On startup, smake reads all environment variables (except the SHELL
environment) into make macros. The following environment variables
affect the behavior of smake.
FORCE_SHELL If the FORCE_SHELL environment is present, smake behaves as
if the special target .FORCE_SHELL: appeared in a makefile.
LANG Sets up a default value for internationalization variables
that are unset or NULL:
LC_ALL If set, this overrides any other internationalization vari‐
ables.
LC_CTYPE Determine the the interpretation of byte sequences.
LC_MESSAGES Determine the diagnostic messages.
MAKE_LEVEL This variable is managed by smake to track nested smake
calls. It is initialized with 1 and exported. Nested calls
to smake increment the level.
MAKEFLAGS This variable is set up by smake in order to forward com‐
mand line options to nested calls to smake. In order to do
this, smake sets the content of the MAKEFLAGS variable to
contain a list of single character option letters. The
option -f is not forwarded via the MAKEFLAGS environment.
If command line macro definitions in the form name=value
have been specified, the list of option letters is followed
by the string " -- " and by a list of macro definitions.
If any of the name=value command line macro definitions
contains a space (' ') or a backslash ('\'), these charac‐
ters are escaped by a single backslash.
As required by POSIX, smake accepts all possible variants
of formatting the content of the MAKEFLAGS environment.
See section Special Macros for more information on the
MAKEFLAGS environment.
PATH The PATH environment variable is used by smake when calling
commands. When PATH is modified, this may cause that spe‐
cific commands cannot be found or that a different imple‐
mentation with different behavior is found instead.
PROJECTDIR This enviroment variable controls the way SCCS history
files are searched for. See sccs(1) for more information.
ASYNCHRONOUS EVENTS
If not already ignored by the shell, smake catches SIGHUP, SIGINT,
SIGQUIT and SIGTERM and removes the current target unless the current
target is a directory, the current target is a prerequisite of the spe‐
cial target .PRECIOUS or the special target .PHONY or one of the
options: -t, -q, -p or -n have been specified.
As bash(1) is known to handle signals in a non POSIX compliant way
because bash sets up different process groups for non-interactive com‐
mands, smake actively propagates the signals named above in case that
the autoconfiguration identified /bin/sh to be bash based.
EXIT STATUS
When the -q option is specified, smake exits with one of the following
values:
0 Successful completion.
1 The target was not up-to-date.
-1 (255)
A command line usage error or makefile parsing error occurred.
>0 An error occurred.
When the -q option is not specified, smake exits with one of the fol‐
lowing values:
0 Successful completion.
-1 (255)
A command line usage error or makefile parsing error occurred.
>0 An error occurred.
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 ALSOsh(1), sccs(1), sysctl(2), sysinfo(2), uname(2), makefiles(4),
makerules(4)NOTES
If a platform uses a shell that does not handle signals correctly and
smake does not implement the work around that was mentioned above in
the section ASYNCHRONOUS EVENTS, sub makes may continue to run even
though the top level make was killed by a signal.
In order to be able to abort complex make structures after a failed
command was encountered, the shell needs to behave correctly with the
-e option. Bash version 3.x in general and the Korn Shell variant that
comes with HP-UX are known to handle the -e option in a non-POSIX com‐
pliant way. If the autoconfiguration tests detect a non-compliant
/bin/sh and there is a working Bourne Shell available under /bin/bosh
or /opt/schily/bin/bosh, smake will use this bosh as the default shell.
See the schily source consolidation at:
ftp://ftp.berlios.de/pub/schily/.
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 consid‐
ered 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 ver‐
sions 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 com‐
plicated shell scripts, you need to escape the end of line with a back‐
slash to keep all commands on one virtual shell command line.
Smake tries to be as POSIX compliant as possible.
POSIX does not cover everything that is needed to write portable make‐
files 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 implementations
since ~ 1980. In addition, it is most unlikely that different make
implementations although POSIX compliant, are compatible enough to
maintain large projects. For these reasons, it seems to be better to
have a portable make implementation like smake.
BUGS
SCCS retrieval is not yet implemented.
A command line that contains the macro $(MAKE) is always executed, even
when in POSIX mode. This is an itended conflict with the POSIX stan‐
dard since POSIX.1-2008.
Built in library handling is not yet implemented.
There are currently no other known bugs. As smake since spring 1993 is
used as the reference make program for the SCHILY (Sing) makefile sys‐
tem, 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.schilling@fokus.fraunhofer.de
Joerg Schilling 12/12/29 SMAKE(1)
