One of the advantages of Make is that it’s POSIX standard and should therefore be provided on a wide range of systems. Most builds rely on many tools which are not standard and therefore must be installed. Often such configuration is pushed outside of the build into some combination of build environment standardization and instructions. This approach is subject to drift issues over time; as the technologies used, versions thereof, and general system configurations evolve over time environments are likely to enter states which are incompatible with the build. Initially captured information is unlikely to provide efficient guidance to reconcile specific incompatibilities between an environment that may have previously adhered to expectations.
While many of these issues can be addressed through use of tools which provide some form of dependency control (which should typically be in place for deployments) there may be reasons such approaches are suboptimal for local development. Such tools may often also introduce additional churn as different artifacts and phases of the project may have different dependencies which can cause either increased overhead around tailoring multiple such configurations or relying on merged configurations representing the union of all such dependencies which are likely to be bloated and which would spawn a geometric number of variations as what would otherwise be independent changes are commingled. In any case this often just leads to moving the goalposts since such tools are also likely to be non-standard and subject to the same issue (albeit with more self-contained fixes). This leads to the common self-referential bootstrapping problem with which Make can help.
Make can validate the build environment and provide specific feedback for any detected potential issues. This enables the project itself to clearly communicate its needs.
First we can define what to do if a dependency is missing. I personally like to not have to remember things and so I want systems to tell me what to do as much as they can rather than me having to remember or figure anything out.
If a dependency is missing the build can error out with either installation instructions for the missing dependency or a standard messge if such instructions have not been defined.
missing-command = $(error $(or ${${1}_INSTALL}, '${1}' is missing; please install ${1}))The above allows for specialized installation instructions, a quick
explanation of the syntax for make novices is that the above would be
called with an argument of the form
$(call missing-command,foo) where that parameter would
replace all of the ${1}s above including the first one
which leads to a nested expansion. Continuing with foo as
an example this produces the equivalent of
$(error $(or ${foo_INSTALL},...).
Defining such a variable therefore enables instructions for that command. Those variables could defined or sourced in any way that aids in organizing them. In simple cases this could just be within the Makefile itself yielding an example such as:
define docker_INSTALL
docker is missing!
Please install using your package manager or from https://www.docker.com/
On OS x with homebrew you can run `brew install docker`
endefThe above enables better feedback when something is missing which empowers the failure scenario, but this needs to be plugged in to the logic which actually determines failure or success. This involves a bit more Make magic using a pattern borrowed from John Graham-Cumming that will be referenced later.
There are numerous ways to attempt to locate a command: I tend to use
which as it is an obvious choice and has served me well.
I’ve seen other alternatives used though it should be kept in mind that
some solutions may not immediately align with the environment in which
Make will execute (e.g. Make doesn’t by default run the same shell
likely to used as a login shell).
This enables defining a variable which should be used in place of the
command name, and this will enable deferred evaluation which means that
the logic here could (and typically will) be evaluated on each
use of the variable. This is somewhat inefficient as it involves calling
out to a shell and so this will make use of populating an internal
_<name>_which variable to act as a cache. The shape
of the logic therefore corresponds to:
missing-command defined
aboverequired-command = $(or ${_${1}_which}, \
$(eval _${1}_which=$(shell which ${1})), \
${_${1}_which}, \
$(call missing-command,${1}))As just referenced the above supports deferred evaluation. The
commands themselves are unlikely to change and so could presumably be
assigned using := which would assign the resolved value
therefore bypassing the benefit of and need for the caching pattern used
above. As mentioned in the background, however, different parts of the
build are likely to have different dependencies and such dependencies
may be provdided through different channels (such as being within a
called container). It would therefore be better to validate dependency
installation as they are needed rather than doing so eagerly and causing
build failures for dependencies which would have factored in to the
relevant build graph. Therefore = should be preferred over
:= when dependency variables are defined and for any other
assignments which reference them.
Usage of this therefore revolves around assigning variables which are then used elsewhere:
DOCKER = $(call required-command,docker)
...
MY_DOCKER_CALL = ${DOCKER} run ${MY_DOCKER_OPTS} ${IMAGE}
...
${BUILD_DIR}app.iid: ${DOCKER_SRCS}
${DOCKER} build --iidfile ${@} ${BUIlD_ARGS} ${BUILD_CONTEXT_DIR}