smake - maintain, update, and regenerate programs

smake [ options ] [ -f makefilename ] [ target1...targetn ]

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.

-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.

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.

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

[<tab> command]
...

"Make directives

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.

Any variable defined by a line in the form:

varname= val

may referenced by either: $(varname) or ${varname}.

.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:00smake-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.

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.

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

Pattern Matching Rules

<tab> dependency_command
...

Suffix Rules

<tab> dependency_command
...

Simple Suffix Rules

<tab> dependency_1_command
...

"": .o
	$(CC) -o $@ $<

.o: .c .s
	$(CC) -c $<
	$(AS) -o $*.o $<

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 > $@

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.

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.

sh(1), makefiles(4), makerules(4)

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.

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.

Jorg 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