BMAKE(1)

πŸ“¦
this version Β· 7 versions
, in debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

🌸 NAME 🌸

bmake β€” maintain program dependencies

okay bestie, welcome to the BMAKE(1) page from the General Commands Manual πŸ’– this is the whole vibe, let's get into it.


✨ SYNOPSIS ✨

bmake [-BeikNnqrstWwX] [-C directory] [-D variable] [-d flags]
      [-f makefile] [-I directory] [-J private] [-j max_jobs]
      [-m directory] [-T file] [-V variable] [-v variable]
      [variable=value] [target ...]

πŸ¦‹ DESCRIPTION πŸ¦‹

bmake is a program designed to simplify the maintenance of other programs. Its input is a list of specifications as to the files upon which programs and other files depend. If no -f makefile makefile option is given, bmake will try to open makefile then Makefile in order to find the specifications. If the file .depend exists, it is read (see mkdep(1)).

ngl this manual page is intended as a reference document only. For a more thorough description of bmake and makefiles, please refer to PMake - A Tutorial. πŸ“š

bmake will prepend the contents of the MAKEFLAGS environment variable to the command line arguments before parsing them. periodt.

The options are as follows:

  • -B β€” Try to be backwards compatible by executing a single shell per command and by executing the commands to make the sources of a dependency line in sequence.
  • -C directory β€” Change to directory before reading the makefiles or doing anything else. If multiple -C options are specified, each is interpreted relative to the previous one: -C / -C etc is equivalent to -C /etc.
  • -D variable β€” Define variable to be 1, in the global context.
  • -d [-]flags β€” Turn on debugging, and specify which portions of bmake are to print debugging information. Unless the flags are preceded by β€˜-’ they are added to the MAKEFLAGS environment variable and will be processed by any child make processes. By default, debugging information is printed to standard error, but this can be changed using the F debugging flag. The debugging output is always unbuffered; in addition, if debugging is enabled but debugging output is not directed to standard output, then the standard output is line buffered. Flags is one or more of the following:
    • A β€” Print all possible debugging information; equivalent to specifying all of the debugging flags.
    • a β€” Print debugging information about archive searching and caching.
    • C β€” Print debugging information about current working directory.
    • c β€” Print debugging information about conditional evaluation.
    • d β€” Print debugging information about directory searching and caching.
    • e β€” Print debugging information about failed commands and targets.
    • F[+]filename β€” Specify where debugging output is written. This must be the last flag, because it consumes the remainder of the argument. If the character immediately after the β€˜F’ flag is β€˜+’, then the file will be opened in append mode; otherwise the file will be overwritten. If the file name is β€˜stdout’ or β€˜stderr’ then debugging output will be written to the standard output or standard error output file descriptors respectively (and the β€˜+’ option has no effect). Otherwise, the output will be written to the named file. If the file name ends β€˜.%d’ then the β€˜%d’ is replaced by the pid.
    • f β€” Print debugging information about loop evaluation.
    • g1 β€” Print the input graph before making anything.
    • g2 β€” Print the input graph after making everything, or before exiting on error.
    • g3 β€” Print the input graph before exiting on error.
    • j β€” Print debugging information about running multiple shells.
    • l β€” Print commands in Makefiles regardless of whether or not they are prefixed by β€˜@’ or other "quiet" flags. Also known as "loud" behavior. πŸ”₯
    • M β€” Print debugging information about "meta" mode decisions about targets.
    • m β€” Print debugging information about making targets, including modification dates.
    • n β€” Don't delete the temporary command scripts created when running commands. These temporary scripts are created in the directory referred to by the TMPDIR environment variable, or in /tmp if TMPDIR is unset or set to the empty string. The temporary scripts are created by mkstemp(3), and have names of the form makeXXXXXX.
NOTE: This can create many files in TMPDIR or /tmp, so use with care. 😭 bestie pls be careful.
  • p β€” Print debugging information about makefile parsing.
  • s β€” Print debugging information about suffix-transformation rules.
  • t β€” Print debugging information about target list maintenance.
  • V β€” Force the -V option to print raw values of variables, overriding the default behavior set via .MAKE.EXPAND_VARIABLES.
  • v β€” Print debugging information about variable assignment.
  • x β€” Run shell commands with -x so the actual commands are printed as they are executed.
  • -e β€” Specify that environment variables override macro assignments within makefiles.
  • -f makefile β€” Specify a makefile to read instead of the default β€˜makefile’. If makefile is β€˜-’, standard input is read. Multiple makefiles may be specified, and are read in the order specified.
  • -I directory β€” Specify a directory in which to search for makefiles and included makefiles. The system makefile directory (or directories, see the -m option) is automatically included as part of this list.
  • -i β€” Ignore non-zero exit of shell commands in the makefile. Equivalent to specifying β€˜-’ before each command line in the makefile.
  • -J private β€” This option should not be specified by the user.

When the j option is in use in a recursive build, this option is passed by a make to child makes to allow all the make processes in the build to cooperate to avoid overloading the system.

fr fr, do not touch this one, it's a backstage pass only πŸ‘‘
  • -j max_jobs β€” Specify the maximum number of jobs that bmake may have running at any one time. The value is saved in .MAKE.JOBS. Turns compatibility mode off, unless the B flag is also specified. When compatibility mode is off, all commands associated with a target are executed in a single shell invocation as opposed to the traditional one shell invocation per line. This can break traditional scripts which change directories on each command invocation and then expect to start with a fresh environment on the next line. It is more efficient to correct the scripts rather than turn backwards compatibility on.
  • -k β€” Continue processing after errors are encountered, but only on those targets that do not depend on the target whose creation caused the error.
  • -m directory β€” Specify a directory in which to search for sys.mk and makefiles included via the <file>-style include statement. The -m option can be used multiple times to form a search path. This path will override the default system include path: /usr/share/mk. Furthermore the system include path will be appended to the search path used for "file"-style include statements (see the -I option).

If a file or directory name in the -m argument (or the MAKESYSPATH environment variable) starts with the string ".../" then bmake will search for the specified file or directory named in the remaining part of the argument string. The search starts with the current directory of the Makefile and then works upward towards the root of the file system. If the search is successful, then the resulting directory replaces the ".../" specification in the -m argument. If used, this feature allows bmake to easily search in the current source tree for customized sys.mk files (e.g., by using ".../mk/sys.mk" as an argument). 🧚 so clever honestly

  • -n β€” Display the commands that would have been executed, but do not actually execute them unless the target depends on the .MAKE special source (see below).
  • -N β€” Display the commands which would have been executed, but do not actually execute any of them; useful for debugging top-level makefiles without descending into subdirectories.
  • -q β€” Do not execute any commands, but exit 0 if the specified targets are up-to-date and 1, otherwise.
  • -r β€” Do not use the built-in rules specified in the system makefile.
  • -s β€” Do not echo any commands as they are executed. Equivalent to specifying β€˜@’ before each command line in the makefile.
  • -T tracefile β€” When used with the -j flag, append a trace record to tracefile for each job started and completed.
  • -t β€” Rather than re-building a target as specified in the makefile, create it or update its modification time to make it appear up-to-date.
  • -V variable β€” Print the value of variable. Do not build any targets. Multiple instances of this option may be specified; the variables will be printed one per line, with a blank line for each null or undefined variable. The value printed is extracted from the global context after all makefiles have been read. By default, the raw variable contents (which may include additional unexpanded variable references) are shown. If variable contains a β€˜$’ then the value will be recursively expanded to its complete resultant text before printing. The expanded value will also be printed if .MAKE.EXPAND_VARIABLES is set to true and the -dV option has not been used to override it. Note that loop-local and target-local variables, as well as values taken temporarily by global variables during makefile processing, are not accessible via this option. The -dv debug mode can be used to see these at the cost of generating substantial extraneous output.

🌸 okay that's the first chunk, more coming bestie, stay with me πŸ’–

  • -v variable β€” it's giving -V energy, but the variable gets expanded allll the way to its complete value. no trimming, no half-measures. πŸ’…
  • -W β€” every single warning that shows up while the makefile is being parsed? bestie, that's an error now. sorry, we don't do "just a warning" here. πŸ”₯
  • -w β€” prints those "entering directory" / "leaving directory" messages, both pre and post processing. it's like narration for your build. πŸ¦‹
  • -X β€” do not export the variables passed on the command line to the environment individually. (they still go out through the MAKEFLAGS environment variable, so don't panic. 🫢) this one's lowkey a lifesaver on systems with a small limit on the size of command arguments.
  • variable=value β€” sets the variable variable to value. normally, everything you pass on the command line also gets exported to sub-makes in the environment, and the -X flag is what turns that behavior off. variable assignments should follow options for POSIX compatibility, but no ordering is enforced, so. chaos permitted, technically. 🌸

okay so real talk, there are seven different types of lines in a makefile: file dependency specifications, shell commands, variable assignments, include statements, conditional directives, for loops, and comments. that's the whole lineup. ✨

and in general, lines may be continued from one line to the next by ending them with a backslash (\). the trailing newline character and the initial whitespace on the following line get compressed into a single space. no cap.

🌸 FILE DEPENDENCY SPECIFICATIONS 🌸

dependency lines are made of one or more targets, an operator, and zero or more sources. it creates a relationship where the targets "depend" on the sources and are usually created from them. the exact relationship between the target and the source is decided by whichever operator separates them. three operators, three whole personalities:

  • : β€” a target is considered out-of-date if its modification time is less than those of any of its sources. sources for a target accumulate over dependency lines when this operator is used. the target gets removed if bmake is interrupted. πŸ’€
  • ! β€” targets are always re-created, but not until all sources have been examined and re-created as necessary. sources for a target accumulate over dependency lines when this operator is used too. target gets removed if bmake is interrupted.
  • :: β€” if no sources are specified, the target is always re-created. otherwise, a target is considered out-of-date if any of its sources has been modified more recently than the target. sources for a target do not accumulate over dependency lines when this operator is used. and the target will not be removed if bmake is interrupted. she's independent like that. πŸ‘‘

targets and sources may contain the shell wildcard values ?, *, [], and {}. the values ?, *, and [] may only be used as part of the final component of the target or source, and they must be used to describe existing files. {} doesn't have to describe existing files though β€” she's flexible. expansion happens in directory order, not alphabetically like the shell does it. πŸŒ€

✨ SHELL COMMANDS ✨

each target may have one or more lines of shell commands associated with it, normally used to create the target. every single line in this script must be preceded by a tab.

for historical reasons, spaces are not accepted. not even one. i don't make the rules (i do not, in fact, make the rules). πŸ™ˆ

while targets can appear in many dependency lines if you want, by default only one of these rules may be followed by a creation script. but if the :: operator is used, all rules may include scripts, and the scripts get executed in the order they're found. slay.

each line is treated as a separate shell command, unless the end of line is escaped with a backslash (\), in which case that line and the next one get combined. and if the first characters of the command are any combination of @, +, or -, the command is treated specially:

  • @ causes the command not to be echoed before it's executed. sneaky. 🀫
  • + causes the command to be executed even when -n is given. this is similar to the effect of the .MAKE special source, except the effect can be limited to a single line of a script.
  • - in compatibility mode causes any non-zero exit status of the command line to be ignored. it's giving "we don't see it, so it didn't happen". πŸ’…

when bmake is run in jobs mode with -j max_jobs, the entire script for the target is fed to a single instance of the shell. in compatibility (non-jobs) mode, each command runs in a separate process. if the command contains any shell meta characters (`#=|^(){};&<>*?[]:$`\\n) it will be passed to the shell; otherwise bmake will attempt direct execution. if a line starts with - and the shell has ErrCtl enabled, then failure of the command line will be ignored as in compatibility mode. otherwise - affects the entire job; the script will stop at the first command line that fails, but the target will not be deemed to have failed. ✨

makefiles should be written so that the mode of bmake operation does not change their behavior. for example, any command which needs to use "cd" or "chdir" without potentially changing the directory for subsequent commands should be put in parentheses so it executes in a subshell. to force the use of one shell, escape the line breaks so as to make the whole script one command. like this:

avoid-chdir-side-effects:
        @echo Building $@ in `pwd`
        @(cd ${.CURDIR} && ${MAKE} $@)
        @echo Back in `pwd`

ensure-one-shell-regardless-of-mode:
        @echo Building $@ in `pwd`; \
        (cd ${.CURDIR} && ${MAKE} $@); \
        echo Back in `pwd`

since bmake will chdir(2) to .OBJDIR before executing any targets, each child process starts with that as its current working directory. 🏠

πŸ’œ VARIABLE ASSIGNMENTS πŸ’œ

variables in make are much like variables in the shell, and, by tradition, consist of all upper-case letters. that's just the vibe, okay?

πŸŽ€ Variable assignment modifiers

the five operators that can be used to assign values to variables are as follows:

  • = β€” assign the value to the variable. any previous value is overridden. gone. bye. πŸ‘‹
  • += β€” append the value to the current value of the variable.
  • ?= β€” assign the value to the variable if it is not already defined.
  • := β€” assign with expansion, i.e. expand the value before assigning it to the variable. normally, expansion isn't done until the variable is referenced.
NOTE: references to undefined variables are not expanded. this can cause problems when variable modifiers are used. 😭
  • != β€” expand the value and pass it to the shell for execution, then assign the result to the variable. any newlines in the result get replaced with spaces.

any white-space before the assigned value is removed; and if the value is being appended, a single space is inserted between the previous contents of the variable and the appended value. tidy. 🧹

variables are expanded by surrounding the variable name with either curly braces ({}) or parentheses (()), preceded by a dollar sign ($). if the variable name contains only a single letter, the surrounding braces or parentheses are not required β€” but bestie, that shorter form is not recommended. we don't do that here. πŸ’…

if the variable name contains a dollar, then the name itself is expanded first. this allows almost arbitrary variable names, however names containing dollar, braces, parenthesis, or whitespace are really best avoided! (like, really.) 🚫

if the result of expanding a variable contains a dollar sign ($) the string is expanded again. yes, again. recursion is a lifestyle.

variable substitution occurs at three distinct times, depending on where the variable is being used:

  1. Variables in dependency lines are expanded as the line is read.
  2. Variables in shell commands are expanded when the shell command is executed.
  3. ".for" loop index variables are expanded on each loop iteration. note that other variables are not expanded inside loops, so the following example code:
.for i in 1 2 3
a+=     ${i}
j=      ${i}
b+=     ${j}
.endfor

all:
        @echo ${a}
        @echo ${b}

will print:

1 2 3
3 3 3

because while ${a} contains "1 2 3" after the loop is executed, ${b} contains "${j} ${j} ${j}" which expands to "3 3 3" since after the loop completes ${j} contains "3". it's giving time-loop betrayal. 😭

🌈 Variable classes

the four different classes of variables, in order of increasing precedence, are:

  • Environment variables β€” variables defined as part of bmake's environment.
  • Global variables β€” variables defined in the makefile or in included makefiles.
  • Command line variables β€” variables defined as part of the command line.
  • Local variables β€” variables that are defined specific to a certain target. πŸ‘‘

local variables are all built in and their values vary magically from target to target. it is not currently possible to define new local variables. sorry. the seven local variables are as follows:

  • .ALLSRC β€” the list of all sources for this target; also known as >.
  • .ARCHIVE β€” the name of the archive file; also known as !.
  • .IMPSRC β€” in suffix-transformation rules, the name/path of the source from which the target is to be transformed (the "implied" source); also known as <. it is not defined in explicit rules.
  • .MEMBER β€” the name of the archive member; also known as %.
  • .OODATE β€” the list of sources for this target that were deemed out-of-date; also known as ?.
  • .PREFIX β€” the file prefix of the target, containing only the file portion, no suffix or preceding directory components; also known as *. the suffix must be one of the known suffixes declared with .SUFFIXES or it will not be recognized. πŸ‘€
  • .TARGET β€” the name of the target; also known as @. for compatibility with other makes this is an alias for .ARCHIVE in archive member rules.

the shorter forms (>, !, <, %, ?, *, and @) are permitted for backward compatibility with historical makefiles and legacy POSIX make and are not recommended. like, they work, but we're not doing that. πŸŽ€

variants of these variables with the punctuation followed immediately by D or F, e.g. $(@D), are legacy forms equivalent to using the :H and :T modifiers. these forms are accepted for compatibility with AT&T System V UNIX makefiles and POSIX but are not recommended. πŸ’œ

Four of the local variables can be used in sources on dependency lines, because they expand to the proper value for each target on that line. Those four cuties are .TARGET, .PREFIX, .ARCHIVE, and .MEMBER. ✨

Additional built-in variables

On top of all that, bmake sets or just ~knows~ about the following variables, no cap:

  • $ β€” a single dollar sign $, meaning $$ expands to one single dollar sign. That's it, that's the whole vibe. πŸ’…
  • .ALLTARGETS β€” the list of all targets encountered in the Makefile. If it's evaluated during Makefile parsing, it only lists the targets encountered thus far (so it's giving ✨work in progress✨).
  • .CURDIR β€” a path to the directory where bmake was executed. Refer to the description of PWD for more details, bestie.
  • .INCLUDEDFROMDIR β€” the directory of the file this Makefile was included from.
  • .INCLUDEDFROMFILE β€” the filename of the file this Makefile was included from.
  • MAKE β€” the name that bmake was executed with (argv[0]). For compatibility, bmake also sets .MAKE with the same value. The preferred variable to use is the environment variable MAKE because it's more compatible with other versions of bmake and cannot be confused with the special target that has the same name. πŸ‘‘
  • .MAKE.DEPENDFILE β€” names the makefile (default .depend) from which generated dependencies are read.
  • .MAKE.EXPAND_VARIABLES β€” a boolean that controls the default behavior of the -V option. If true, variable values printed with -V are fully expanded; if false, the raw variable contents (which may include additional unexpanded variable references) are shown. πŸ¦‹
  • .MAKE.EXPORTED β€” the list of variables exported by bmake.
  • .MAKE.JOBS β€” the argument to the -j option.
  • .MAKE.JOB.PREFIX β€” if bmake is run with j, then output for each target is prefixed with a token --- target ---, the first part of which can be controlled via .MAKE.JOB.PREFIX. If .MAKE.JOB.PREFIX is empty, no token is printed. For example:
.MAKE.JOB.PREFIX=${.newline}---${.MAKE:T}[${.MAKE.PID}]

would produce tokens like ---make[1234] target ---, making it easier to track the degree of parallelism being achieved. Parallelism tracking? Obsessed. πŸ”₯

  • MAKEFLAGS β€” the environment variable MAKEFLAGS may contain anything that may be specified on bmake's command line. Anything specified on bmake's command line is appended to the MAKEFLAGS variable, which is then entered into the environment for all programs which bmake executes. πŸ’«
  • .MAKE.LEVEL β€” the recursion depth of bmake. The initial instance of bmake will be 0, and an incremented value is put into the environment to be seen by the next generation. This allows tests like:
.if ${.MAKE.LEVEL} == 0

to protect things which should only be evaluated in the initial instance of bmake. Protect your peace, fr fr. 🫢

  • .MAKE.MAKEFILE_PREFERENCE β€” the ordered list of makefile names (default makefile, Makefile) that bmake will look for.
  • .MAKE.MAKEFILES β€” the list of makefiles read by bmake, which is useful for tracking dependencies. Each makefile is recorded only once, regardless of the number of times it was read. (It's not doing repeats, unlike me replaying my fave song 😭)
  • .MAKE.MODE β€” processed after reading all makefiles. Can affect the mode that bmake runs in. It can contain a number of keywords:
    • compat β€” like -B, puts bmake into "compat" mode.
    • meta β€” puts bmake into "meta" mode, where meta files are created for each target to capture the command run, the output generated, and if filemon(4) is available, the system calls which are of interest to bmake. The captured output can be very useful when diagnosing errors. πŸ’€ (in the helpful way)
    • curdirOk= bf β€” normally bmake will not create .meta files in .CURDIR. This can be overridden by setting bf to a value which represents True.
    • missing-meta= bf β€” if bf is True, then a missing .meta file makes the target out-of-date.
    • missing-filemon= bf β€” if bf is True, then missing filemon data makes the target out-of-date.
    • nofilemon β€” do not use filemon(4).
    • env β€” for debugging, it can be useful to include the environment in the .meta file.
    • verbose β€” if in "meta" mode, print a clue about the target being built. This is useful if the build is otherwise running silently. The message printed is the value of .MAKE.META.PREFIX.
    • ignore-cmd β€” some makefiles have commands which are simply not stable. This keyword causes them to be ignored for determining whether a target is out of date in "meta" mode. See also .NOMETA_CMP.
    • silent= bf β€” if bf is True, when a .meta file is created, mark the target .SILENT.
  • .MAKE.META.BAILIWICK β€” in "meta" mode, provides a list of prefixes which match the directories controlled by bmake. If a file that was generated outside of .OBJDIR but within said bailiwick is missing, the current target is considered out-of-date. Bailiwick is such a word, I'm obsessed. πŸ’œ
  • .MAKE.META.CREATED β€” in "meta" mode, this variable contains a list of all the meta files updated. If not empty, it can be used to trigger processing of .MAKE.META.FILES.
  • .MAKE.META.FILES β€” in "meta" mode, this variable contains a list of all the meta files used (updated or not). This list can be used to process the meta files to extract dependency information.
  • .MAKE.META.IGNORE_PATHS β€” provides a list of path prefixes that should be ignored, because the contents are expected to change over time. The default list includes: /dev /etc /proc /tmp /var/run /var/tmp
  • .MAKE.META.IGNORE_PATTERNS β€” provides a list of patterns to match against pathnames. Ignore any that match.
  • .MAKE.META.IGNORE_FILTER β€” provides a list of variable modifiers to apply to each pathname. Ignore if the expansion is an empty string.
  • .MAKE.META.PREFIX β€” defines the message printed for each meta file updated in "meta verbose" mode. The default value is:
Building ${.TARGET:H:tA}/${.TARGET:T}
  • .MAKEOVERRIDES β€” this variable is used to record the names of variables assigned to on the command line, so that they may be exported as part of MAKEFLAGS. This behavior can be disabled by assigning an empty value to .MAKEOVERRIDES within a makefile. Extra variables can be exported from a makefile by appending their names to .MAKEOVERRIDES. MAKEFLAGS is re-exported whenever .MAKEOVERRIDES is modified. The way it just re-exports itself the second anything changes… main character energy tbh. ✨
  • .MAKE.PATH_FILEMON β€” if bmake was built with filemon(4) support, this is set to the path of the device node. This allows makefiles to test for this support.
  • .MAKE.PID β€” the process-id of bmake.
  • .MAKE.PPID β€” the parent process-id of bmake.
  • .MAKE.SAVE_DOLLARS β€” value should be a boolean that controls whether $$ are preserved when doing := assignments. The default is false, for backwards compatibility. Set to true for compatibility with other makes. If set to false, $$ becomes $ per normal evaluation rules.
  • MAKE_PRINT_VAR_ON_ERROR β€” when bmake stops due to an error, it sets .ERROR_TARGET to the name of the target that failed, .ERROR_CMD to the commands of the failed target, and in "meta" mode it also sets .ERROR_CWD to the getcwd(3), and .ERROR_META_FILE to the path of the meta file (if any) describing the failed target. It then prints its name and the value of .CURDIR as well as the value of any variables named in MAKE_PRINT_VAR_ON_ERROR. 😭 (the error-handling is lowkey so thorough tho)
  • .newline β€” this variable is simply assigned a newline character as its value. This allows expansions using the :@ modifier to put a newline between iterations of the loop rather than a space. For example, the printing of MAKE_PRINT_VAR_ON_ERROR could be done as:
${MAKE_PRINT_VAR_ON_ERROR:@v@$v='${$v}'${.newline}@}
  • .OBJDIR β€” a path to the directory where the targets are built. Its value is determined by trying to chdir(2) to the following directories in order and using the first match:
    1. ${MAKEOBJDIRPREFIX}${.CURDIR}

(Only if MAKEOBJDIRPREFIX is set in the environment or on the command line.)

  1. ${MAKEOBJDIR}

(Only if MAKEOBJDIR is set in the environment or on the command line.)

  1. ${.CURDIR}/obj.${MACHINE}
  1. ${.CURDIR}/obj
  2. /usr/obj/${.CURDIR}
  3. ${.CURDIR}

Variable expansion happens on the value before it gets used, so bestie you can absolutely write stuff like

${.CURDIR:S,^/usr/src,/var/obj,}

and it just works. This is especially handy with MAKEOBJDIR, no cap.

.OBJDIR can be changed right inside the makefile using the special target .OBJDIR. And in every single case, bmake will chdir(2) into that directory if it actually exists, then set .OBJDIR and PWD to it before it runs any targets. Periodt.

  • .PARSEDIR β€” a path to the directory of the current Makefile being parsed. 🫢
  • .PARSEFILE β€” the basename of the current Makefile being parsed. Heads up: this one and .PARSEDIR are only set while the Makefiles are being parsed. If you wanna keep their values around, assign them to a variable using assignment with expansion, aka :=. πŸ’…
  • .PATH β€” a variable that's the list of directories bmake will search for files. Bestie, update the search list with the .PATH target, not the variable itself. πŸ™ˆ
  • PWD β€” an alternate path to the current directory. bmake normally sets .CURDIR to the canonical path from getcwd(3). But if the environment variable PWD is set and points at the current directory, then bmake sets .CURDIR to PWD's value instead. This whole behavior gets disabled if MAKEOBJDIRPREFIX is set, or if MAKEOBJDIR contains a variable transform. And PWD gets set to the value of .OBJDIR for every program bmake runs. ✨
  • .TARGETS β€” the list of targets explicitly named on the command line, if there are any.
  • VPATH β€” colon-separated (:) lists of directories that bmake will search for files. Ngl, this variable only exists for compatibility with old make programs, so use .PATH instead, okay? πŸ’€

✨ Variable modifiers ✨

Variable expansion can be modified to pick or tweak each word of the variable β€” and a "word" here just means a white-space delimited sequence of characters, iykyk. The general format of a variable expansion is:

${variable[:modifier[:...]]}

Every modifier kicks off with a colon, which you can escape with a backslash (\). πŸŽ€

And a whole set of modifiers can come from a variable too, like this:

modifier_variable=modifier[:...]
${variable:${modifier_variable}[:...]}

In this case the first modifier in the modifier_variable does not start with a colon, because that colon has to show up in the referencing variable. And if any of the modifiers in the modifier_variable contain a dollar sign ($), you gotta double them so they don't expand too early. πŸ¦‹

The supported modifiers are, bestie, an entire buffet:

  • :E β€” replaces each word in the variable with its suffix.
  • :H β€” replaces each word in the variable with everything but the last component.
  • :Mpattern β€” selects only the words that match pattern. The standard shell wildcard characters (*, ?, and []) work here. You can escape the wildcards with a backslash (\). And because of the way values get split into words, matched, then joined back up, a construct like
${VAR:M*}

will normalize the inter-word spacing β€” nuking all leading and trailing space and squishing multiple consecutive spaces down to single spaces. Slay.

  • :Npattern β€” identical to :M, except it selects all the words that do not match pattern.
  • :O β€” orders every word in the variable alphabetically.
  • :Or β€” orders every word in the variable in reverse alphabetical order.
  • :Ox β€” randomizes the words in the variable. The results will be different every time you refer to the modified variable, so use assignment with expansion (:=) if you don't want that chaos. For example:
LIST=                   uno due tre quattro
RANDOM_LIST=            ${LIST:Ox}
STATIC_RANDOM_LIST:=    ${LIST:Ox}

all:
        @echo "${RANDOM_LIST}"
        @echo "${RANDOM_LIST}"
        @echo "${STATIC_RANDOM_LIST}"
        @echo "${STATIC_RANDOM_LIST}"

may produce output similar to:

quattro due tre uno
tre due quattro uno
due uno quattro tre
due uno quattro tre
  • :Q β€” quotes every shell meta-character in the variable, so it can be handed to the shell safely. 🫢
  • :q β€” quotes every shell meta-character in the variable and doubles $ characters, so it can survive being passed safely through recursive invocations of bmake. This is equivalent to: :S/\$/&&/g:Q.
  • :R β€” replaces each word in the variable with everything but its suffix.
  • :range[=count] β€” the value becomes an integer sequence representing the words of the original value, or the supplied count.
  • :gmtime[=utc] β€” the value is a format string for strftime(3), using gmtime(3). If a utc value isn't given, or it's 0, the current time is used.
  • :hash β€” computes a 32-bit hash of the value and encodes it as hex digits. πŸ”₯
  • :localtime[=utc] β€” the value is a format string for strftime(3), using localtime(3). If a utc value isn't given, or it's 0, the current time is used.
  • :tA β€” tries to convert the variable to an absolute path using realpath(3). If that fails, the value is left unchanged.
  • :tl β€” converts the variable to lower-case letters.
  • :tsc β€” words in the variable are normally separated by a space on expansion. This modifier sets the separator to the character c. If c is omitted, then no separator is used at all. The common escapes (including octal numeric codes) work as expected.
  • :tu β€” converts the variable to upper-case letters.
  • :tW β€” makes the value be treated as a single word (possibly with embedded white space in it). See also :[*].
  • :tw β€” makes the value be treated as a sequence of words delimited by white space. See also :[@].
  • :S/old_string/new_string/[1gW] β€” modifies the first occurrence of old_string in the variable's value, replacing it with new_string. If you append a g to the last slash of the pattern, all occurrences in each word get replaced. If you append a 1 to the last slash, only the first word is affected. If you append a W, the value is treated as a single word (possibly with embedded white space). If old_string begins with a caret (^), old_string is anchored at the beginning of each word. If old_string ends with a dollar sign ($), it's anchored at the end of each word. Inside new_string, an ampersand (&) gets replaced by old_string (without any ^ or $). Any character can be used as the delimiter for the parts of the modifier string. The anchoring, ampersand and delimiter characters can all be escaped with a backslash (\).

Variable expansion happens the normal way inside both old_string and new_string, with one single exception: a backslash is used to prevent expansion of a dollar sign ($), not a preceding dollar sign like it usually is. πŸ™ˆ

  • :C/pattern/replacement/[1gW] β€” the :C modifier is just like :S, except the old and new strings aren't simple strings at all β€” they're an extended regular expression (see regex(3)) string pattern and an ed(1)-style string replacement. Normally, the first occurrence of pattern in each word of the value gets substituted with replacement. The 1 modifier makes the substitution apply to at most one word; the g modifier makes it apply to as many instances of the search pattern as occur in the word or words it's found in; the W modifier makes the value be treated as a single word (possibly with embedded white space). Ngl, 1 and g are orthogonal β€” the former says whether multiple words can be affected, the latter whether multiple substitutions can happen inside each affected word. πŸ‘‘

Same as with :S, the pattern and replacement get variable-expanded before being parsed as regular expressions.

  • :T β€” replaces each word in the variable with its last component.
  • :u β€” removes adjacent duplicate words (like uniq(1)). πŸ’…
  • :?true_string:false_string β€” if the variable name (not its value), when parsed as a .if conditional expression, evaluates to true, return true_string as its value; otherwise return false_string. And because the variable name is what's used as the expression, :? has to be the first modifier after the variable name itself β€” which will, of course, usually contain variable expansions. A super common oopsie is trying to use expressions like
${NUMBERS:M42:?match:no}

which actually just tests defined(NUMBERS). To figure out whether any words match "42", you need something like:

${"${NUMBERS:M42}" != "":?match:no}.
  • :old_string=new_string β€” this is the AT&T System V UNIX style variable substitution. It has to be the last modifier specified. If old_string or new_string don't contain the pattern matching character %, then it's assumed they're anchored at the end of each word, so only suffixes or entire words can be replaced. Otherwise % is the substring of old_string to be replaced in new_string. If only old_string contains the pattern matching character %, and old_string matches, then the result is new_string. If only new_string contains the pattern matching character %, then it isn't treated specially and it's printed as a literal % on match. And if there's more than one pattern matching character (%) in either new_string or old_string, only the first instance is treated specially (as the pattern character); all subsequent instances are treated as regular characters.

okay so variable expansion happens the normal way inside both old_string and new_string πŸ’– with one tiny exception: a backslash stops a dollar sign ($) from expanding, not a preceding dollar sign like you'd usually expect. periodt.

  • :@temp@string@ β€” this is the loop expansion mechanism from the OSF Development Environment (ODE) make ✨ unlike .for loops, expansion happens at the time of reference. You assign temp to each word in the variable and evaluate string. The ODE convention says temp should start and end with a period. For example:
${LINKS:@.LINK.@${LN} ${TARGET} ${.LINK.}@}

However a single character variable is often more readable:

${MAKE_PRINT_VAR_ON_ERROR:@v@$v='${$v}'${.newline}@}
  • :_[=var] β€” save the current variable value in $_ or the named var for later reference πŸ“ example usage:
M_cmpv.units = 1 1000 1000000
M_cmpv = S,., ,g:_:range:@i@+ $${_:[-$$i]} \
\* $${M_cmpv.units:[$$i]}@:S,^,expr 0 ,1:sh

.if ${VERSION:${M_cmpv}} < ${3.1.12:L:${M_cmpv}}

Here $_ is used to save the result of the :S modifier which is later referenced using the index values from :range. πŸ’…

  • :Unewval β€” if the variable is undefined, newval is the value. If the variable is defined, the existing value is returned. This is another ODE make feature. It's handy for setting per-target CFLAGS for instance:
${_${.TARGET:T}_CFLAGS:U${DEF_CFLAGS}}

If a value is only required if the variable is undefined, use:

${VAR:D:Unewval}
  • :Dnewval β€” if the variable is defined, newval is the value. ✨
  • :L β€” the name of the variable is the value. πŸ’–
  • :P β€” the path of the node which has the same name as the variable is the value. If no such node exists or its path is null, then the name of the variable is used. In order for this modifier to work, the name (node) must at least have appeared on the rhs of a dependency. 🌈
  • :!cmd! β€” the output of running cmd is the value. πŸ”₯
  • :sh β€” if the variable is non-empty it is run as a command and the output becomes the new value. πŸ’…
  • ::=str β€” the variable is assigned the value str after substitution. This modifier and its variations are useful in obscure situations such as wanting to set a variable when shell commands are being parsed. These assignment modifiers always expand to nothing, so if appearing in a rule line by themselves should be preceded with something to keep bmake happy. 😭

The :: helps avoid false matches with the AT&T System V UNIX style := modifier and since substitution always occurs the ::= form is vaguely appropriate.

  • ::?=str β€” as for ::= but only if the variable does not already have a value. πŸŽ€
  • ::+=str β€” append str to the variable. ✨
  • ::!=cmd β€” assign the output of cmd to the variable. πŸ’–
  • :[range] β€” selects one or more words from the value, or performs other operations related to the way in which the value is divided into words. πŸ¦‹

Ordinarily, a value is treated as a sequence of words delimited by white space. Some modifiers suppress this behavior, causing a value to be treated as a single word (possibly containing embedded white space). An empty value, or a value that consists entirely of white-space, is treated as a single word. For the purposes of the :[] modifier, the words are indexed both forwards using positive integers (where index 1 represents the first word), and backwards using negative integers (where index -1 represents the last word). πŸ‘‘

The range is subjected to variable expansion, and the expanded result is then interpreted as follows:

  • index β€” selects a single word from the value. πŸ’…
  • start..end β€” selects all words from start to end, inclusive. For example, :[2..-1] selects all words from the second word to the last word. If start is greater than end, then the words are output in reverse order. For example, :[-1..1] selects all the words from last to first. If the list is already ordered, then this effectively reverses the list, but it is more efficient to use :Or instead of :O:[-1..1]. πŸ”₯
  • * β€” causes subsequent modifiers to treat the value as a single word (possibly containing embedded white space). Analogous to the effect of "$*" in Bourne shell. 🌸
  • 0 β€” means the same as :[*]. ✨
  • @ β€” causes subsequent modifiers to treat the value as a sequence of words delimited by white space. Analogous to the effect of "$@" in Bourne shell. πŸ’œ
  • # β€” returns the number of words in the value. πŸ’―

🌈 INCLUDE STATEMENTS, CONDITIONALS AND FOR LOOPS 🌈

okay so bestie, bmake is giving full C-programming-language energy here β€” makefile inclusion, conditional structures, and for loops, all of it. and the way you mark every single one of these structures? with a line whose very first character is a single dot (.</pink>) πŸ’… that's the tell, that's the vibe check.

Files get included with either .include <file> or .include "file". Variables sitting between the angle brackets or the double quotes get expanded to form the file name. Angle brackets β†’ the included makefile is expected to be in the system makefile directory. Double quotes β†’ the including makefile's own directory plus any directories you specified with the -I option get searched before the system makefile directory. and for compatibility with other versions of bmake, include file ... is also accepted (yes, no dot, we love a legacy moment ✨).

  • .include β†’ normal include, errors are very much not ignored.
  • .-include / .sinclude β†’ if the include statement is written either of these ways, errors locating and/or opening include files are ignored πŸ™ˆ
  • .dinclude β†’ not only are errors locating and/or opening include files ignored, but stale dependencies within the included file will be ignored too, just like .MAKE.DEPENDFILE.

Conditional expressions also get preceded by a single dot as the first character of a line. the possible conditionals are, in order, iconic:

  • .error message β€” the message is printed along with the name of the makefile and line number, and then bmake will exit. like, we're done here πŸ’€
  • .export variable ... β€” export the specified global variable. if you don't give it a variable list, all globals get exported except for internal variables (those that start with .). this is not affected by the -X flag, so it should be used with caution. and for compatibility with other bmake programs, export variable=value is also accepted. appending a variable name to .MAKE.EXPORTED is equivalent to exporting a variable. 🫢
  • .export-env variable ... β€” same as .export, except the variable is not appended to .MAKE.EXPORTED. this is what lets you export a value to the environment that's different from the one bmake uses internally. sneaky, we love her πŸ’…
  • .export-literal variable ... β€” same as .export-env, except that variables in the value are not expanded.
  • .info message β€” the message is printed along with the name of the makefile and line number.
  • .undef variable β€” un-define the specified global variable. ⚠️ only global variables may be un-defined.
  • .unexport variable ... β€” the literal opposite of .export. the specified global variable gets removed from .MAKE.EXPORTED. if no variable list is provided, all globals are unexported and .MAKE.EXPORTED is deleted. bye πŸ‘‹
  • .unexport-env β€” unexport all globals previously exported and clear the environment inherited from the parent. this operation will cause a memory leak of the original environment, so it should be used sparingly. testing for .MAKE.LEVEL being 0 would make sense. also note that any variables which originated in the parent environment should be explicitly preserved if you want them around. for example:
.if ${.MAKE.LEVEL} == 0
PATH := ${PATH}
.unexport-env
.export PATH
.endif

would result in an environment containing only PATH, which is the minimal useful environment. actually, .MAKE.LEVEL will also be pushed into the new environment. cute of her πŸŽ€

  • .warning message β€” the message prefixed by warning: is printed along with the name of the makefile and line number.
  • .if [!]expression [operator expression ...] β€” test the value of an expression.
  • .ifdef [!]variable [operator variable ...] β€” test the value of a variable.
  • .ifndef [!]variable [operator variable ...] β€” test the value of a variable.
  • .ifmake [!]target [operator target ...] β€” test the target being built.
  • .ifnmake [!] target [operator target ...] β€” test the target being built.
  • .else β€” reverse the sense of the last conditional. πŸ™ƒ
  • .elif [!] expression [operator expression ...] β€” a combination of .else followed by .if.
  • .elifdef [!]variable [operator variable ...] β€” a combination of .else followed by .ifdef.
  • .elifndef [!]variable [operator variable ...] β€” a combination of .else followed by .ifndef.
  • .elifmake [!]target [operator target ...] β€” a combination of .else followed by .ifmake.
  • .elifnmake [!]target [operator target ...] β€” a combination of .else followed by .ifnmake.
  • .endif β€” end the body of the conditional. periodt. πŸ¦‹

the operators, bestie 🧚

  • || β€” logical OR.
  • && β€” logical AND, and it's of higher precedence than ||.

as in C, bmake will only evaluate a conditional as far as is necessary to determine its value. parentheses may be used to change the order of evaluation. the boolean operator ! may be used to logically negate an entire conditional, and it is of higher precedence than &&. πŸ‘‘


the value of expression ✨

  • defined β€” takes a variable name as an argument and evaluates to true if the variable has been defined.
  • make β€” takes a target name as an argument and evaluates to true if the target was specified as part of bmake's command line, or was declared the default target (either implicitly or explicitly, see .MAIN) before the line containing the conditional.
  • empty β€” takes a variable, with possible modifiers, and evaluates to true if the expansion of the variable would result in an empty string.
  • exists β€” takes a file name as an argument and evaluates to true if the file exists. the file is searched for on the system search path (see .PATH).
  • target β€” takes a target name as an argument and evaluates to true if the target has been defined.
  • commands β€” takes a target name as an argument and evaluates to true if the target has been defined and has commands associated with it.

Expression may also be an arithmetic or string comparison. variable expansion is performed on both sides of the comparison, after which the integral values are compared. a value is interpreted as hexadecimal if it is preceded by 0x, otherwise it is decimal; octal numbers are not supported. the standard C relational operators are all supported. if, after variable expansion, either the left or right hand side of a == or != operator is not an integral value, then string comparison is performed between the expanded variables. if no relational operator is given, it is assumed that the expanded variable is being compared against 0, or an empty string in the case of a string comparison. no cap. 🌸

when bmake is evaluating one of these conditional expressions and it encounters a (white-space separated) word it doesn't recognize, either the make or defined expression is applied to it, depending on the form of the conditional. if the form is .ifdef, .ifndef, or .if, the defined expression is applied. similarly, if the form is .ifmake or .ifnmake, the make expression is applied.

if the conditional evaluates to true, the parsing of the makefile continues as before. if it evaluates to false, the following lines are skipped. in both cases this continues until a .else or .endif is found. πŸ’–


for loops πŸ”

for loops are typically used to apply a set of rules to a list of files. the syntax of a for loop is:

.for variable [variable ...] in expression
⟨make-rules⟩
.endfor

after the for expression is evaluated, it is split into words. on each iteration of the loop, one word is taken and assigned to each variable, in order, and these variables are substituted into the make-rules inside the body of the for loop. and here's the thing bestie β€” the number of words must come out even. that is, if there are three iteration variables, the number of words provided must be a multiple of three. no leftovers, no stragglers, it's giving balance. ⭐


πŸ’¬ COMMENTS πŸ’¬

comments begin with a hash (#) character, anywhere but in a shell command line, and continue to the end of an unescaped new line. that's it, that's the whole vibe. πŸ“

✨ SPECIAL SOURCES (ATTRIBUTES) ✨

okay bestie, these are the source attributes that change how a target behaves. lowkey powerful, fr fr. πŸ’…

  • .EXEC β€” Target is never out of date, but always execute commands anyway. it's giving "run me every single time, no questions" ✨
  • .IGNORE β€” Ignore any errors from the commands associated with this target, exactly as if they all were preceded by a dash (β€˜-’). no cap, errors just get ignored. πŸ™ˆ
  • .MADE β€” Mark all sources of this target as being up-to-date. periodt. πŸ’–
  • .MAKE β€” Execute the commands associated with this target even if the -n or -t options were specified. Normally used to mark recursive bmakes. recursive bmake main character energy. πŸ‘‘
  • .META β€” Create a meta file for the target, even if it is flagged as .PHONY, .MAKE, or .SPECIAL. Usage in conjunction with .MAKE is the most likely case. In "meta" mode, the target is out-of-date if the meta file is missing. meta file vibe check. πŸ”₯
  • .NOMETA β€” Do not create a meta file for the target. Meta files are also not created for .PHONY, .MAKE, or .SPECIAL targets. nope, no meta here. 🚫
  • .NOMETA_CMP β€” Ignore differences in commands when deciding if target is out of date. This is useful if the command contains a value which always changes. If the number of commands change, though, the target will still be out of date. The same effect applies to any command line that uses the variable .OODATE, which can be used for that purpose even when not otherwise needed or desired:
skip-compare-for-some:
    @echo this will be compared
    @echo this will not ${.OODATE:M.NOMETA_CMP}
    @echo this will also be compared

The :M pattern suppresses any expansion of the unwanted variable. iconic. πŸŽ€

  • .NOPATH β€” Do not search for the target in the directories specified by .PATH. not the path, bestie. πŸ¦‹
  • .NOTMAIN β€” Normally bmake selects the first target it encounters as the default target to be built if no target was specified. This source prevents this target from being selected. not me being the default. πŸ’€
  • .OPTIONAL β€” If a target is marked with this attribute and bmake can't figure out how to create it, it will ignore this fact and assume the file isn't needed or already exists. optional? we love a flexible queen. πŸ’œ
  • .PHONY β€” The target does not correspond to an actual file; it is always considered to be out of date, and will not be created with the -t option. Suffix-transformation rules are not applied to .PHONY targets. fake file, real attitude. πŸ’…
  • .PRECIOUS β€” When bmake is interrupted, it normally removes any partially made targets. This source prevents the target from being removed. protect this target at all costs. 🫢
  • .RECURSIVE β€” Synonym for .MAKE. same vibe, different name. ✨
  • .SILENT β€” Do not echo any of the commands associated with this target, exactly as if they all were preceded by an at sign (β€˜@’). shhh, no echo. 🀫
  • .USE β€” Turn the target into bmake's version of a macro. When the target is used as a source for another target, the other target acquires the commands, sources, and attributes (except for .USE) of the source. If the target already has commands, the .USE target's commands are appended to them. macro moment. 🌸
  • .USEBEFORE β€” Exactly like .USE, but prepend the .USEBEFORE target commands to the target. before, not after. periodt. πŸ’–
  • .WAIT β€” If .WAIT appears in a dependency line, the sources that precede it are made before the sources that succeed it in the line. Since the dependents of files are not made until the file itself could be made, this also stops the dependents being built unless they are needed for another branch of the dependency tree. So given:
x: a .WAIT b
    echo x
a:
    echo a
b: b1
    echo b
b1:
    echo b1

the output is always β€˜a’, β€˜b1’, β€˜b’, β€˜x’. The ordering imposed by .WAIT is only relevant for parallel makes. parallel make said "wait your turn". ⏳


🎯 SPECIAL TARGETS 🎯

Special targets may not be included with other targets, i.e. they must be the only target specified. no sharing the spotlight. πŸ‘‘

  • .BEGIN β€” Any command lines attached to this target are executed before anything else is done. first, obviously. ✨
  • .DEFAULT β€” This is sort of a .USE rule for any target (that was used only as a source) that bmake can't figure out any other way to create. Only the shell script is used. The .IMPSRC variable of a target that inherits .DEFAULT's commands is set to the target's own name. default fallback energy. πŸ’…
  • .DELETE_ON_ERROR β€” If this target is present in the makefile, it globally causes make to delete targets whose commands fail. (By default, only targets whose commands are interrupted during execution are deleted. This is the historical behavior.) This setting can be used to help prevent half-finished or malformed targets from being left around and corrupting future rebuilds. delete on error? dramatic but valid. πŸ’€
  • .END β€” Any command lines attached to this target are executed after everything else is done. last but not least. πŸŽ€
  • .ERROR β€” Any command lines attached to this target are executed when another target fails. The .ERROR_TARGET variable is set to the target that failed. See also MAKE_PRINT_VAR_ON_ERROR. error handler main character. 😭
  • .IGNORE β€” Mark each of the sources with the .IGNORE attribute. If no sources are specified, this is the equivalent of specifying the -i option. ignore it bestie. πŸ™ˆ
  • .INTERRUPT β€” If bmake is interrupted, the commands for this target will be executed. interrupt? we still run. πŸ”₯
  • .MAIN β€” If no target is specified when bmake is invoked, this target will be built. the chosen one. πŸ‘‘
  • .MAKEFLAGS β€” This target provides a way to specify flags for bmake when the makefile is used. The flags are as if typed to the shell, though the -f option will have no effect. flags but make it makefile. ✨
  • .NOPATH β€” Apply the .NOPATH attribute to any specified sources. no path, no problem. πŸ¦‹
  • .NOTPARALLEL β€” Disable parallel mode. one at a time, bestie. ⏳
  • .NO_PARALLEL β€” Synonym for .NOTPARALLEL, for compatibility with other pmake variants. same energy. πŸ’œ
  • .OBJDIR β€” The source is a new value for β€˜.OBJDIR’. If it exists, bmake will chdir(2) to it and update the value of β€˜.OBJDIR’. objdir glow up. 🌈
  • .ORDER β€” The named targets are made in sequence. This ordering does not add targets to the list of targets to be made. Since the dependents of a target do not get built until the target itself could be built, unless β€˜a’ is built by another part of the dependency graph, the following is a dependency loop:
.ORDER: b a
b: a

The ordering imposed by .ORDER is only relevant for parallel makes. order in the court. βš–οΈ

  • .PATH β€” The sources are directories which are to be searched for files not found in the current directory. If no sources are specified, any previously specified directories are deleted. If the source is the special .DOTLAST target, then the current working directory is searched last. path search but make it fashion. πŸ”
  • .PATH.suffix β€” Like .PATH but applies only to files with a particular suffix. The suffix must have been previously declared with .SUFFIXES. suffix-specific path. πŸŽ€
  • .PHONY β€” Apply the .PHONY attribute to any specified sources. phony and proud. πŸ’…
  • .PRECIOUS β€” Apply the .PRECIOUS attribute to any specified sources. If no sources are specified, the .PRECIOUS attribute is applied to every target in the file. precious cargo. 🫢
  • .SHELL β€” Sets the shell that bmake will use to execute commands. The sources are a set of field=value pairs.
    • name β€” This is the minimal specification, used to select one of the built-in shell specs; sh, ksh, and csh.
    • path β€” Specifies the path to the shell.
    • hasErrCtl β€” Indicates whether the shell supports exit on error.
    • check β€” The command to turn on error checking.
    • ignore β€” The command to disable error checking.
    • echo β€” The command to turn on echoing of commands executed.
    • quiet β€” The command to turn off echoing of commands executed.
    • filter β€” The output to filter after issuing the quiet command. It is typically identical to quiet.
    • errFlag β€” The flag to pass the shell to enable error checking.
    • echoFlag β€” The flag to pass the shell to enable command echoing.
    • newline β€” The string literal to pass the shell that results in a single newline character when used outside of any quoting characters.

Example:

.SHELL: name=ksh path=/bin/ksh hasErrCtl=true \
        check="set -e" ignore="set +e" \
        echo="set -v" quiet="set +v" filter="set +v" \
        echoFlag=v errFlag=e newline="'\n'"
  • .SILENT β€” Apply the .SILENT attribute to any specified sources. If no sources are specified, the .SILENT attribute is applied to every command in the file. silent but deadly. 🀫
  • .STALE β€” This target gets run when a dependency file contains stale entries, having .ALLSRC set to the name of that dependency file. stale? not on my watch. πŸ“
  • .SUFFIXES β€” Each source specifies a suffix to bmake. If no sources are specified, any previously specified suffixes are deleted. It allows the creation of suffix-transformation rules.

Example:

.SUFFIXES: .o
.c.o:
    cc -o ${.TARGET} -c ${.IMPSRC}

🌍 ENVIRONMENT 🌍

bmake uses the following environment variables, if they exist: MACHINE, MACHINE_ARCH, MACHINE_MULTIARCH, MAKE, MAKEFLAGS, MAKEOBJDIR, MAKEOBJDIRPREFIX, MAKESYSPATH, PWD, and TMPDIR.

MAKEOBJDIRPREFIX and MAKEOBJDIR may only be set in the environment or on the command line to bmake and not as makefile variables; see the description of β€˜.OBJDIR’ for more details.


πŸ“ FILES πŸ“

  • .depend β€” list of dependencies
  • Makefile β€” list of dependencies
  • makefile β€” list of dependencies
  • sys.mk β€” system makefile
  • /usr/share/mk β€” system makefile directory

πŸ’« COMPATIBILITY πŸ’«

Okay bestie, gather round, because this is the part where we talk about how bmake gets along with other makes, and the answer is... it's giving "we're all speaking the same language but also absolutely not." 🫢

The basic make syntax is compatible between different versions of make; however the special variables, variable modifiers and conditionals are not. Periodt.


🌸 Older versions 🌸

An incomplete list of changes in older versions of bmake (iykyk, this is the lore):

  • The way that .for loop variables are substituted changed after NetBSD 5.0 so that they still appear to be variable expansions. In particular this stops them being treated as syntax, and removes some obscure problems using them in .if statements. ✨
  • The way that parallel makes are scheduled changed in NetBSD 4.0 so that .ORDER and .WAIT apply recursively to the dependent nodes. The algorithms used may change again in the future. No cap, it's a moving target. πŸ¦‹

πŸŽ€ Other make dialects πŸŽ€

Other make dialects (GNU make, SVR4 make, POSIX make, etc.) do not support most of the features of bmake as described in this manual. Most notably:

  • The .WAIT and .ORDER declarations and most functionality pertaining to parallelization. (GNU make supports parallelization but lacks these features needed to control it effectively.) 😭
  • Directives, including for loops and conditionals and most of the forms of include files. (GNU make has its own incompatible and less powerful syntax for conditionals.)
  • All built-in variables that begin with a dot. πŸ’…
  • Most of the special sources and targets that begin with a dot, with the notable exception of .PHONY, .PRECIOUS, and .SUFFIXES.
  • Variable modifiers, except for the
:old=new

string substitution, which does not portably support globbing with % and historically only works on declared suffixes.

  • The $> variable even in its short form; most makes support this functionality but its name varies.

Some features are somewhat more portable, such as assignment with +=, ?=, and !=. The .PATH functionality is based on an older feature VPATH found in GNU make and many versions of SVR4 make; however, historically its behavior is too ill-defined (and too buggy) to rely upon. So like... proceed with caution, bestie. πŸ™ˆ

The $@ and $< variables are more or less universally portable, as is the $(MAKE) variable. Basic use of suffix rules (for files only in the current directory, not trying to chain transformations together, etc.) is also reasonably portable. Slay. πŸ’…βœ¨


πŸ‘€ SEE ALSO πŸ‘€


πŸ“œ HISTORY πŸ“œ

bmake is derived from NetBSD make(1). It uses autoconf to facilitate portability to other platforms. 🌈

A make command appeared in Version 7 AT&T UNIX. This make implementation is based on Adam De Boor's pmake program which was written for Sprite at Berkeley. It was designed to be a parallel distributed make running jobs on different machines using a daemon called β€œcustoms”. Iconic behavior, honestly. πŸ‘‘

Historically the target/dependency β€œFRC” has been used to FoRCe rebuilding (since the target/dependency does not exist... unless someone creates an β€œFRC” file). πŸ“


πŸ’€ BUGS πŸ’€

The make syntax is difficult to parse without actually acting on the data. For instance, finding the end of a variable's use should involve scanning each of the modifiers, using the correct terminator for each field. In many places make just counts {} and () in order to find the end of a variable expansion. It's giving "close enough," ngl.

There is no way of escaping a space character in a filename. Genuinely, that's just the rules. 😭


And that's the whole page, bestie!! πŸ₯³ This one's from the Debian crew, dated June 5, 2020, and it's the BMAKE(1) manual page β€” go forth and build responsibly, you absolute main character. πŸŽ€πŸ’–βœ¨

πŸ“¦ where this page comes from