For new users, the relationship between make and the shell can be confusing. I think people get thrown off by the make-specific syntax in makefiles — all those colons and at signs and percents. But the truth is that most of the content in a makefile is commands that are executed by the shell.
With GNU make, there are two ways to invoke shell commands from a makefile:
Recipes: the go-to-guy of shell commands in make
The recipe of a rule is the workhorse of gmake/shell integration. Structurally, the recipe is the list of commands used to generate the output file — each of the tab-initiated lines following a target: prereq declaration in the makefile. In the following makefile fragment, I highlighted the recipe in red (note that the commands shown here are for illustration only; in a real makefile, you should use variables like $(CC), $@ and $< to ensure the makefile is portable and flexible):
foo.o: foo.c foo.h
echo 'building foo.o'
gcc -c -o foo.o foo.c
echo 'done with foo.o'
You can think of the commands in a recipe as being invoked using the common idiom sh -c “command”. That means that you can use standard shell constructs like process pipelines and for loops. In turn, that flexibility means that recipes should be your “go-to guy” when it comes to invoking shell commands from a makefile. Want to preprocess your sources with sed before sending it to the compiler? Just tweak your recipe:
foo.o: foo.c foo.h
echo 'building foo.o'
sed -e 's/foo/bar/g' foo.c | gcc -c -o foo.o -xc -
echo 'done with foo.o'
So recipes are the primary way to invoke shell commands in make. Here are some guidelines to remember:
If possible, gmake will invoke commands directly rather using the shell.
Essentially, gmake scans the command-line for shell built-ins (like for and if) and “shell special characters” (like | and &). If none of these are present in the command-line, gmake will
avoid the overhead of the shell invocation by invoking the command directly (literally just using execve to run the command).
Note that if you change the shell gmake uses by setting the SHELL makefile variable, then gmake will always use the shell to invoke commands, since it can’t know what commands and characters are “special” to your custom shell.
gmake expands command-lines before executing them.
Command expansion is why you can use gmake features like variables (eg, $@) and functions (eg, $(foreach)) in the recipe. It is also why you must use double dollar signs if you want to reference shell variables in your recipe:
abc: def
let foo=1 ; echo $$foo
gmake executes each line in a recipe separately.
That means that there’s no sharing of state from one command to the next, and it’s why recipes like the following don’t work as expected:
abc: def
let foo=1
echo $$foo
Because this recipe contains two lines, gmake executes it in two pieces:
sh -c "let foo=1"
sh -c "echo $foo"
It’s obvious why this recipe doesn’t work, when written out that way: the variable assignment occurs in one shell, but the reference occurs in another. But there’s an easy way around this: line continuations. You’ve probably seen this technique in use:
abc: def
let foo=1 ; \
echo $$foo
Now gmake executes the recipe using a single shell invocation:
sh -c "let foo=1 ; echo $foo"
Nota bene: if you are using gmake 3.82 or later, you can enable the .ONESHELL feature, which causes gmake to invoke the entire recipe using a single shell invocation, even if you haven’t used line continuations.
The $(shell) function
The $(shell) function is the second way to invoke the shell from gmake. It’s intended purpose is to capture the output of a command into a gmake variable. For example, you could save the name of the current user in the variable USERNAME this way:
USERNAME := $(shell whoami)
$(shell) takes a single argument, the command to run. Just like commands in recipes, if there are shell constructs in the command gmake will invoke it using sh -c “command”; otherwise, gmake will invoke the command directly. Likewise, gmake will expand variable and function references in the command before invoking it, so you must use double-dollar-signs to reference shell variables in that context:
TARGETS := $(shell for n in `seq -w 1 10`; do echo $$n; done)
Here are some guidelines to help you use $(shell) correctly and effectively:
If you’re not capturing the result of $(shell) to a variable, you’re probably misusing $(shell).
Here’s a real-world example of how not to use $(shell):
$(shell touch targets.mk)
include targets.mk
all: $(TARGETS)
The intent here was to ensure that targets.mk exists before gmake tries to include it. One problem with this approach is that it will touch the file every time you invoke the makefile, even on a “no touch” build! The correct way to accomplish this is with a proper rule for targets.mk:
include targets.mk
all: $(TARGETS)
targets.mk:
@touch targets.mk
If targets.mk doesn’t exist, it will be created. Note that this particular example exploits the makefile remaking feature in gmake; in general though, if you’re using $(shell) this way, you can probably transform that usage into a regular rule, and get better performance and a more robust makefile for your trouble.
If you’re using $(shell) in a recipe, you’re probably misusing $(shell).
Another real-world example of $(shell) abuse:
foo.o: foo.c
$(shell sed -e 's/foo/bar/' $< | gcc -o $@ -xc -)
Now that you know that recipes are implicitly using the shell, you can see that this use of $(shell) is utterly superfluous. The problem with this is that it moves the work into the command expansion phase, which means it can’t run in parallel with gmake. The fix for this one is to just drop the $(shell) call:
foo.o: foo.c
sed -e 's/foo/bar/' $< | gcc -o $@ -xc -
Always use := assignment with $(shell).
I’ve written before about the importance of using := assignment with $(shell). In short: not using := assignment can cause your makefile to invoke the shell far more often than you realize, which can be a performance problem, and leave you with unpredictable build results. Always use := assignment with $(shell).
Conclusion
Hopefully now you see that the relationship between gmake and the shell is not so mysterious after all. Just remember: when in doubt, use a recipe, and don’t use $(shell) unless you’re capturing the result into a variable.
eric melski's blog.melski.net 
