|
NAMEsmake - maintain, update, and regenerate programsSYNOPSISsmake [ options ] [ -f makefilename ] [ target1...targetn ]DESCRIPTIONSmake 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 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 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
See the description of the special target .POSIX for more information.
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. OPERANDSThe following operands are supported:
All macro definitions are evaluated before any target it build. BASICSSmake 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 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 following 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.
A limited set of built in rules is compiled into smake. A more complete set is read from the file ./defaults.smk or /opt/schily/share/lib/smake/defaults.smk. Makefile FormatSmake 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 ExecutionCommand lines associated with rules are sequentially executed line by line in an own process or shell. All commands may use constructs supported 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 command 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:
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 simple 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 addition. Target rulesA 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
Automake FeaturesSmake 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 macrosThe special purpose macros that have names that match MAKE_* (see section 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 targetsThe 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 associated 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 FilesIn 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 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 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 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. MacrosMacro DefinitionsMacros 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 uses 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++. Warning: Macros created with the ::= operator will cause the += operator to evaluate macros on the right side of the operator before doing the actual append operation. To avoid unpredictable behavior, it is recommended to use at least one lower case character in the name of macros that have been created using the ::= operator. An alternate macro definitions uses the form: macroname +:= value to append value to the current definition for macroname after value has been evaluated. The string $$ is not expanded with the +:= operator, it is left unmodified while the right side is expanded. 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 assign value to the current definition for macroname in case that macroname does not yet have a definition. 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. The := operator has been introduced in 2005 as a temporary feature. It currently is an alias to the final :::= operator explained below. Note that SunPro make was the first make implementation that
introduced := in 1986 already, but for a different incompatible
purpose, GNU make in 1990 introduced := with a another different
incompatible purpose that later has been standardized by POSIX issue 8 as
the ::= operator. BSD make implements the same behavior as
smake for the := assignment operator. A makefile that uses
:= thus is non-portable for use with different make implementations.
smake may change its behavior in the future and implement a SunPro
Make compatible conditional macro assignment instead of the current
behavior for :=. For this reason, it is recommended to use
:::= instead of :=.
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. Macros created with this operator are not expanded on use. Note that this is the POSIX variant of the GNU immediate assignment that is portable to make implementations that are compatible to POSIX issue 8 and used in POSIX mode. The ::= operator is only supported by smake when in POSIX mode. Warning: This operator may cause unpredictable behavior, since it creates a different type of macro that is not expanded on use and that causes a different behavior with the += operator. In order to avoid the unpredictable behavior with the += operator, it is recommended to avoid the ::= operator in favor of :::=, or to use at least one lower case letter as a marker in the names of all macros that have been created with the ::= operator. 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. The string $$ is not expanded with the :::= operator, it is left unmodified while the right side is expanded. Note that this is a naming for the immediate expansion assignment operator that is usable in portable makefiles with make implementations compatible to POSIX issue 8. The operator :::= should be used in favor of := and ::= for all new makefiles. A macro definition that uses the form: macroname:sh= command will call command and define the macro value to be the output of command when the line is read by the parser. Macro ReferencesMacros 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 makefile. Macro references are expanded under the following circumstances:
Macro SubstitutionMacro references may be used to substitute macro values. There are different methods for macro substitution.Suffix Replacement Macro ReferencesA 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 ReferencesA 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
replaces foo.o by SCCS/s.foo.c when the macro $(SCCS_HISTFILE) is referenced. The replacement is done on a word by word base and the white space between words is literally retained. If there is no match, the result is unmodified. Shell Replacement Macro ReferencesA 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
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.
.SPACE_IN_NAMES: true
target\ with\ spaces: dependency\ with\ spaces
.SPACE_IN_NAMES:
Special Macros
Dynamic MacrosThere 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:
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 RulesIf 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 dependency file names. Pattern Matching RulesPattern matching rules have been introduced by SunPRO make with SunOS-3.2 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 RulesSuffix 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 current 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 RulesSimple 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 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 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 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 IMPLICIT RULESChanging the implicit rules allows to change the default behavior of smake.Default Simple Suffix RulesThe 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 VARIABLESOn startup, smake reads all environment variables (except the SHELL environment) into make macros. The following environment variables affect the behavior of smake.
ASYNCHRONOUS EVENTSIf 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 special 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 commands, smake actively propagates the signals named above in case that the autoconfiguration identified /bin/sh to be bash based. EXIT STATUSWhen the -q option is specified, smake exits with one of the following values:
When the -q option is not specified, smake exits with one of the following values:
FILES
SEE ALSOdmake(1), make(1s), sh(1), sccs(1), sysctl(2), sysinfo(2), uname(2), makefiles(4), makerules(4)NOTESIf 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 compliant 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: https://sourceforge.net/projects/schilytools/files/ 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 tries to 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 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. BUGSSCCS 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 standard 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 system, smake is the best choice when compiling projects that are using the SCHILY (Sing) makefile system. AUTHORJoerg Schilling D-13353 Berlin Germany Mail bugs and suggestions to: joerg@schily.net
SOURCE DOWNLOADA frequently updated source code for smake is included in the schilytools project and may be retrieved from the schilytools project at Sourceforge at:http://sourceforge.net/projects/schilytools/ The download directory is: http://sourceforge.net/projects/schilytools/files/ Check for the schily-*.tar.bz2 archives. Less frequently updated source code for the smake project is at: http://sourceforge.net/projects/s-make/files/
Visit the GSP FreeBSD Man Page Interface. |