Go 语言的 Makefile 指南
第7节 高质量的Makefile
❤️ During the winter vacation, I followed up and learned two projects: tiktok project and IAM project, and summarized and practiced the CloudNative project and Go language. I learned a lot in the process.Myblog: http://nsddd.top
低质量的makefile
低质量的 Makefile 文件是什么样的;
build: clean vet
@mkdir -p ./Role
@export GOOS=linux && go build -v .
go vet ./...
go fmt ./...
clean:
rm -rf dashboard上面这个 Makefile 存在不少问题。例如：功能简单，只能完成最基本的编译、格式化等操作，像构建镜像、自动生成代码等一些高阶的功能都没有；扩展性差，没法编译出可在 Mac 下运行的二进制文件；没有 Help 功能，使用难度高；单 Makefile 文件，结构单一，不适合添加一些复杂的管理功能。
所以，我们不光要编写 Makefile，还要编写高质量的 Makefile。那么如何编写一个高质量的 Makefile 呢？我觉得，可以通过以下 4 个方法来实现：
-
打好基础，也就是熟练掌握
Makefile的语法。 -
做好准备工作，也就是提前规划
Makefile要实现的功能。 -
进行规划，设计一个合理的
Makefile结构。 -
掌握方法，用好
Makefile的编写技巧。
makefile 如何工作
makefile规则：
target ... : prerequisites ...
command
...-
target
- 可以是一个object file（目标文件），也可以是一个执行文件，还可以是一个标签（label）。对于标签这种特性，在后续的“伪目标”章节中会有叙述。
-
prereqisites
- 生成该target所依赖的文件和/或target
-
command
- 该target要执行的命令（任意的shell命令）
prerequisites中如果有一个以上的文件比target文件要新的话，command所定义的命令就会被执行。
Build and Run
首先两个特别频繁的指令加进去：
build:
go build -o stringifier main.go
go run -race main.gobuild:
我在运行命令中添加了
-race
标志，方便它在运行时在Go代码中检测到
race
情况。
Cleaning and DRYing
构建二进制文件并运行应用程序后，一切正常, 确保我们在执行其他任何操作之前先清理二进制文件。我们更新
Makefile
应该看起来像这样：
clean:
go clean:
我们有两点可以改进 :
-
我们明确地重用了我们的应用程序名, 很自然我们的应用程序名称将在整个
Makefile中的许多地方使用。 -
每次构建应用之前，我们需要先执行
clean的规则。
改进后的
Makefile
APP=stringifier
build: clean
go build -o ${APP} main.go
go run -race main.go
clean:
go clean
更新
: 这个例子之前使用的
rm -r ${APP}
，现在使用
go clean
。
在顶部定义
Makefile
变量，当您调用
make
命令时make将自动引用它们，这样
Makefile
看起来就更整洁、规范了。
PHONY targets
在 Makefile 中，
.PHONY
是一个特殊的目标（target），它用于定义那些不表示实际文件的伪目标（phony target）。
当 Makefile 执行时，它会检查定义的目标是否已经存在或是否需要更新。对于伪目标，由于它们不表示任何实际文件，因此 Makefile 无法检查它们是否已经存在或是否需要更新。为了避免误判，
可以使用
.PHONY
来明确告诉 Makefile 哪些目标是伪目标，以便在执行时跳过对这些目标的检查。
例如，假设 Makefile 中定义了一个 clean 目标用于删除生成的文件，但是 clean 并不表示任何实际的文件，只是一个伪目标。那么，为了确保 Makefile 在执行时不会将 clean 当成一个文件来检查，可以在 Makefile 中添加如下声明：
.PHONY: clean
clean:
rm -f *.o myprogram
这样，当执行 "make clean" 命令时，Makefile 会跳过对 clean 目标的文件检查，直接执行清理命令。同时，如果我们在 Makefile 中定义了一个与 clean 相同名字的文件，Makefile 也不会将其与 clean 目标混淆。因此，使用
.PHONY
声明伪目标可以提高 Makefile 的可读性和可靠性。
默认情况下
，如果一个前置条件或是目录文件已更改，
make
将执行规则。但是由于我们不依赖于
make
来检测文件更改的能力，因此我们会遇到潜在的麻烦。
假设我们的项目目录中有一个名为
build
的文件, 在这个场景下，当你执行
make build
, make一定会检查文件build的更改，由于没有前置条件，因此将始终将
build
文件视为最新的，并且不会执行其规则定义的操作。
为了避免这个问题，你需要先知道
.PHONY
特殊目录(target)是什么意思：
特殊目标
.PHONY
的先决条件被视为phony目标（targets)。 当需要运行时，make会无条件运行其规则，而不管该名称的文件是否存在或其最后修改时间是多少。
所以，你可以通过将目标（target）指定为特殊目标
.PHONY
的先决条件，将目标指定为
.PHONY
。
APP=stringifier
.PHONY: build
build: clean
go build -o ${APP} main.go
.PHONY: run
go run -race main.go
.PHONY: clean
clean:
go clean
现在你已将上述所有的
targets
指定为
phony
, 每次你调用任何
phony
目标（target) 时，make将会执行相应的规则。你还可以一次将所有要指定为
phony
的目标指定为:
.PHONY: build clean run
但是对于非常大的Makefile，不建议这样做因为这可能导致歧义和无法读取。因此，首选方法是在规则定义之前显式设置
phony
目标（target）。
Recursive Make targets
当 Makefile 包含多个目标时，我们可以在 Makefile 中使用递归 Make 来构建这些目标。递归 Make 指的是在 Makefile 中调用另一个 Makefile 来构建其中的目标。
在递归 Make 中，通常有一个顶层 Makefile，该 Makefile 调用其他 Makefile 来构建子目录中的目标。这样的 Makefile 被称为 "递归 Makefile"，而由这个 Makefile 调用的 Makefile 被称为 "子 Makefile"。
在递归 Make 中，每个子 Makefile 负责构建它所在的目录中的目标，然后将构建的结果返回给父 Makefile。递归 Make 的一个常见的问题是，当在子目录中调用 Make 命令时，可能会破坏父目录中的变量设置和规则，因此需要小心地设置变量和规则，以避免不必要的冲突。
递归 Make 的一种常见用法是使用一个称为“递归变量”的特殊变量。递归变量的值可以包含调用另一个 Makefile 的命令，这个命令会返回一个值，可以被递归变量使用。递归变量在递归 Make 中非常有用，因为它们可以帮助子 Makefile 获得父 Makefile 中的变量值。
例如，我们可以在项目的根目录下创建一个名为 "Makefile" 的文件，其内容如下：
codeSUBDIRS = foo bar baz
.PHONY: all $(SUBDIRS)
all: $(SUBDIRS)
$(SUBDIRS):
$(MAKE) -C $@在上面的 Makefile 中，"SUBDIRS" 变量定义了项目的子目录名称。"all" 是一个伪目标，它将调用每个子目录中的 Makefile 来构建所有目标。
$(SUBDIRS) 是一个自动变量，它会展开为 "foo bar baz"。因此，当我们运行 "make all" 命令时，它将首先调用 "make foo"，然后在 "foo" 目录中运行 "make" 命令来构建 "foo" 目录中的目标。接着它会依次调用 "make bar" 和 "make baz" 命令，以此类推。
在子目录的 Makefile 中，我们可以使用和普通 Makefile 中一样的规则和变量定义来构建子目录中的目标。这种方式可以帮助我们轻松地管理复杂的项目，避免代码重复，并提高 Makefile 的可重用性。
现在让我们假设我们在项目中使用的根目录中还有另一个模块
tokenizer
。现在我们的目录结构是这样的：
~/programming/stringifier
├── main.go
├── Makefile
└── tokenizer/
├── main.go
└── Makefile~/programming/stringifier
很自然，某些时候我们也想
build
和
test
我们的
tokenizer
模块。由于它是一个独立的模块也可能是一个独立的项目，在它的目录有如下内容的一个
Makefile
是很有必要的：
# ~/programming/stringifier/tokenizer/Makefile
APP=tokenizer
build:
go build -o ${APP} main.go
现在只要您在
stringifier
项目的根目录中并且想要构建
tokenizer
应用程序，你不会想使用诸如
cd tokenizer && make build && cd -
这样的易受攻击的命令行技巧，而具体的
Makefiles
的规则写在子目录中的方式。幸运的是，
make
可以帮助你解决这个问题。你可以使用
-C
标志和特殊的
${NAME}
变量在其他目录中调用
make targets
。下面是
stringifies
项目最初的Makefile:
# ~/programming/stringifier/Makefile
APP=stringifier
.PHONY: build
build: clean
go build -o ${APP} main.go
.PHONY: run
go run -race main.go
.PHONY: clean
clean:
go clean
.PHONY: build-tokenizer
build-tokenizer:
${MAKE} -C tokenizer build
现在只要你运行
make build-tokenizer
，
make
都将为您处理目录切换，并以更加可读和健壮的方式为您调用正确目录中的正确目标
-c
标志和特殊的
${NAME}
:
-
-C标志：指定 Makefile 文件的目录，让 make 命令在指定的目录下执行 Makefile 文件。例如：
all:
cd subdir && $(MAKE)
上述 Makefile 中的$(MAKE)命令会在当前目录下的subdir目录中执行 Makefile 文件。可以使用-C标志来达到同样的效果：
all:
$(MAKE) -C subdir -
${NAME}变量：在 Makefile 中使用${NAME}变量可以引用环境变量中的值，例如：
all:
echo "PATH is ${PATH}"
上述 Makefile 中的${PATH}变量会展开为当前系统环境变量中的PATH值。
以下是一个用 Go 语言编写的 Makefile 示例，其中使用了
-C
标志和
${NAME}
变量：
# Makefile
APP_NAME := my-app
.PHONY: build
build:
cd cmd/my-app && go build -o ../../bin/$(APP_NAME)
.PHONY: test
test:
go test ./...
.PHONY: clean
clean:
rm -rf bin/*
.PHONY: build-docker
build-docker: build
docker build -t $(APP_NAME) .
.PHONY: run-docker
run-docker: build-docker
docker run -p 8080:8080 $(APP_NAME)
.PHONY: deploy
deploy: build-docker
ssh ${SSH_USER}@${SSH_HOST} "docker pull $(APP_NAME); docker stop $(APP_NAME) || true; docker rm $(APP_NAME) || true; docker run -p 8080:8080 -d --name $(APP_NAME) $(APP_NAME)"
上述 Makefile 中，
build-docker
、
run-docker
和
deploy
等目标中使用了
${APP_NAME}
变量来指定 Docker 镜像的名称，同时使用了
-C
标志来在子目录中执行命令，例如
build
目标中的
cd cmd/my-app && go build
命令。
Targets for Docker commands
现在您希望对应用程序进行容器化，然后为方便起见编写make目标，这是完全可以理解的。
你为docker命令定义了如下规则：
.PHONY: docker-build
docker-build: build
docker build -t stringifier .
docker tag stringifier stringifier:tag
.PHONY: docker-push
docker-push: docker-build
docker push gcr.io/stringifier/stringifier-staging/stringifier:tagdocker命令基本满足需要，但是还有改善的空间，
-
对于新手，你可以再次重用你的
${APP}变量。 - 接下来，您想要更灵活并确保可以轻松控制将映像推送到哪里，无论是您的私人镜像仓库还是其他地方。
- 然后，您希望能够根据用户在命令行上的某些输入将镜像（image）分别推送到与预生产和生产环境有关的两个单独的镜像仓库中。
-
最后，像一个理智的开发人员一样，您想使用当前的git commit sha标记您的镜像（image）。 让我们基于这些问题重新修改下
Makefile：
APP?=application
REGISTRY?=gcr.io/images
COMMIT_SHA=$(shell git rev-parse --short HEAD)
.PHONY: docker-build
docker-build: build
docker build -t ${APP} .
docker tag ${APP} ${APP}:${COMMIT_SHA}
.PHONY: docker-push
docker-push: check-environment docker-build
docker push ${REGISTRY}/${ENV}/${APP}:${COMMIT_SHA}
check-environment:
ifndef ENV
$(error ENV not set, allowed values - `staging` or `production`)
endif现在，让我们回顾下上面的更改：
- 你开始为应用程序名称，镜像名称,提交sha使用变量。
-
您使用特殊的shell函数生成了commit sha。 在这种情况下，您运行了git命令，该命令返回了简短的提交sha，并将其分配给变量
${COMMIT_SHA}，以便稍后在Makefile中使用。 -
您添加了一个新的规则
check-environment，该环境使用make条件检查在调用make时是否指定了ENV变量，这有助于区分预生产及生产环境。
check-environment
的规则如下：
check-environment:
ifndef ENV
$(error ENV not set, allowed values - `staging` or `production`)
endif
使用
ifndef
指令检查变量ENV是否为空值，如果存在，则使用另一个make的提供内置函数，如果出错了，将会在关键字之后抛出具体的错误消息。
$ make docker-push
Makefile:33: *** ENV not set, allowed values - `staging` or `production`. Stop.
$ ENV=staging make docker-push
Success本质上，您要确保docker-push目标具有安全保障，该保障可检查调用目标的用户是否已为ENV变量指定值。
@ 符号
项目的
makefile
中很容易看到 @ 符号的存在，它的意义不同寻常：
## build: Build source code for host platform.
.PHONY: build
build:
@$(MAKE) go.build在Makefile中，@符号用于 抑制Make命令的输出 。当在Makefile中使用@符号时， Make将不会打印出该行命令的输出结果，而是仅仅执行该命令。
在Go语言项目中，我们通常使用Makefile来构建和管理项目。下面是一个简单的Go语言项目Makefile示例：
# 编译二进制文件
build:
@go build -o myapp main.go
# 运行程序
@./myapp
clean:
@rm -f myapp
在上面的示例中，我们定义了三个Makefile命令：
build
，
run
和
clean
。在每个命令的前面，我们都使用了
@
符号来抑制命令的输出。这意味着，当我们在命令行中运行
make build
时，Make命令将会编译Go程序，但不会将编译器的输出打印到终端。
如果我们去掉
@
符号，那么当我们运行
make build
时，Make将会输出编译器的输出，类似于下面的结果：
go build -o myapp main.go
# 输出编译器的输出
因此，使用
@
符号可以使Makefile输出更加干净，仅仅打印出我们关心的内容，而不会输出一堆不必要的信息。
文件搜索 VPATH
在一些大的工程中，有大量的源文件，我们通常的做法是把这许多的源文件分类，并存放在不同的目录中。所以，当make需要去找寻文件的依赖关系时，你可以在文件前加上路径，但最好的方法是把一个路径告诉make，让make在自动去找。
Makefile文件中的特殊变量
VPATH
就是完成这个功能的，如果没有指明这个变量，make只会在当前的目录中去找寻依赖文件和目标文件。如果定义了这个变量，那么，make就会在当前目录找不到的情况下，到所指定的目录中去找寻文件了。
VPATH = src:../headers
上面的定义指定两个目录，“src”和“
../headers
”，
make
会按照这个顺序进行搜索。目录由“冒号”分隔。（当然，当前目录永远是最高优先搜索的地方）
另一个设置文件搜索路径的方法是使用make的“vpath”关键字（注意，它是全小写的），这不是变量，这是一个make的关键字，这和上面提到的那个VPATH变量很类似，但是它更为灵活。它可以指定不同的文件在不同的搜索目录中。这是一个很灵活的功能。它的使用方法有三种：
vpath <pattern> <directories>
为符合模式
<pattern>
的文件指定搜索目录
<directories>
。
vpath <pattern>
清除符合模式
<pattern>
的文件的搜索目录。
vpath清除所有已被设置好了的文件搜索目录。
Help target
一个新成员加入了该项目并想知道Makefile中所有规则的作用，为帮助它们您可以添加一个新目标(target)，该目标将打印所有目标名称以及它们作用的简短描述:
.PHONY: build
## build: build the application
build: clean
@echo "Building..."
@go build -o ${APP} main.go
.PHONY: run
## run: runs go run main.go
go run -race main.go
.PHONY: clean
## clean: cleans the binary
clean:
@echo "Cleaning"
@go clean
.PHONY: setup
## setup: setup go modules
setup:
@go mod init \
&& go mod tidy \
&& go mod vendor
.PHONY: help
## help: prints this help message
help:
@echo "Usage: \n"
@sed -n 's/^##//p' ${MAKEFILE_LIST} | column -t -s ':' | sed -e 's/^/ /'
你先注意下最后一条规则，
help
在这里，您只是使用一些sed魔术来解析和在命令行上打印。 但是要做到这一点，您必要在每条规则之前写了目标名称和简短描述作为注释。 注意另一个特殊变量
$ {MAKEFILE_LIST}
，它是您所引用的所有Makefile的列表，在本例中仅是Makefile。
您会将文件Makefile作为输入传递给sed命令，该命令将解析所有帮助注释并以表格格式将其打印到stdout，以便于阅读。 上一个代码段的
help
目标的输出如下所示：
$ make help
Usage:
build Build the application
clean cleans the binary
run runs go run main.go
docker-build builds docker image
docker-push pushes the docker image
setup set up modules
help prints this help message这些消息很有帮助，对于其他人甚至有时对自己都是一个不错的提示。
Conclusion 结论
Make是一个简单但可高度配置的工具。 在本文中，您遍历了make提供的许多配置和功能，从而为Go应用程序编写了有效而高效的Makefile。
下面是完整的Makefile，其中添加了一些琐碎的规则和变量：
GO111MODULES=on
APP?=stringifier
REGISTRY?=gcr.io/images
COMMIT_SHA=$(shell git rev-parse --short HEAD)
.PHONY: build
## build: build the application
build: clean
@echo "Building..."
@go build -o ${APP} main.go
.PHONY: run
## run: runs go run main.go
go run -race main.go
.PHONY: clean
## clean: cleans the binary
clean:
@echo "Cleaning"
@go clean
.PHONY: test
## test: runs go test with default values
test:
go test -v -count=1 -race ./...
.PHONY: build-tokenizer
## build-tokenizer: build the tokenizer application
build-tokenizer:
${MAKE} -c tokenizer build
.PHONY: setup
## setup: setup go modules
setup:
@go mod init \
&& go mod tidy \
&& go mod vendor
# helper rule for deployment
check-environment:
ifndef ENV
$(error ENV not set, allowed values - `staging` or `production`)
endif
.PHONY: docker-build
## docker-build: builds the stringifier docker image to registry
docker-build: build
docker build -t ${APP}:${COMMIT_SHA} .
.PHONY: docker-push
## docker-push: pushes the stringifier docker image to registry
docker-push: check-environment docker-build
docker push ${REGISTRY}/${ENV}/${APP}:${COMMIT_SHA}
.PHONY: help
## help: Prints this help message
help:
@echo "Usage: \n"
@sed -n 's/^##//p' ${MAKEFILE_LIST} | column -t -s ':' | sed -e 's/^/ /'
熟练makefile语法
IAM 项目的 Makefile 文件：
$ make help
Usage: make <TARGETS> <OPTIONS> ...
Targets:
# 代码生成类命令
gen Generate all necessary files, such as error code files.
# 格式化类命令
format Gofmt (reformat) package sources (exclude vendor dir if existed).
# 静态代码检查
lint Check syntax and styling of go sources.
# 测试类命令
test Run unit test.
cover Run unit test and get test coverage.
# 构建类命令
build Build source code for host platform.
build.multiarch Build source code for multiple platforms. See option PLATFORMS.
# Docker镜像打包类命令
image Build docker images for host arch.
image.multiarch Build docker images for multiple platforms. See option PLATFORMS.
push Build docker images for host arch and push images to registry.
push.multiarch Build docker images for multiple platforms and push images to registry.
# 部署类命令
deploy Deploy updated components to development env.
# 清理类命令
clean Remove all files that are created by building.
# 其他命令，不同项目会有区别
release Release iam
verify-copyright Verify the boilerplate headers for all files.
ca Generate CA files for all iam components.
install Install iam system with all its components.
swagger Generate swagger document.
tools install dependent tools.
# 帮助命令
help Show this help info.
Options:
DEBUG Whether to generate debug symbols. Default is 0.
BINS The binaries to build. Default is all of cmd.
This option is available when using: make build/build.multiarch
Example: make build BINS="iam-apiserver iam-authz-server"
...通常而言，Go 项目的 Makefile 应该实现以下功能：格式化代码、静态代码检查、单元测试、代码构建、文件清理、帮助等等。如果通过 docker 部署，还需要有 docker 镜像打包功能。因为 Go 是跨平台的语言，所以构建和 docker 打包命令，还要能够支持不同的 CPU 架构和平台。为了能够更好地控制 Makefile 命令的行为，还需要支持 Options。
为了方便查看 Makefile 集成了哪些功能，我们需要支持 help 命令。help 命令最好通过解析 Makefile 文件来输出集成的功能，例如：
## help: Show this help info.
.PHONY: help
help: Makefile
@echo -e "\nUsage: make <TARGETS> <OPTIONS> ...\n\nTargets:"
@sed -n 's/^##//p' $< | column -t -s ':' | sed -e 's/^/ /'
@echo "$$USAGE_OPTIONS"
上面的 help 命令，通过解析 Makefile 文件中的
##
注释，获取支持的命令。通过这种方式，我们以后新加命令时，就不用再对 help 命令进行修改了。
常用的 Makefile 核心语法
大多数的 make 都支持“makefile”和“Makefile”这两种文件名，但我建议使用“Makefile”。因为这个文件名第一个字符大写，会很明显，容易辨别。make 也支持
-f
和
--file
参数来指定其他文件名，比如
make -f golang.mk
或者
make --file golang.mk
。
makefile 支持的通配符
Makefile 支持三种类型的通配符，他们是：
*，? 和~
-
*通配符：
*通配符代表任意长度的字符序列，可以匹配任意长度的文件名或路径名中的任意字符。例如，可以使用以下规则来匹配所有.c文件：
SRCS := $(wildcard *.c)这条规则将会将当前目录下所有以.c为后缀的文件名赋值给变量SRCS，使得我们可以方便地引用这些文件。
-
?通配符：
?通配符代表任意单个字符，可以匹配任意长度的文件名或路径名中的一个字符。例如，可以使用以下规则来匹配所有三个字符长的
.txt
文件：
SRCS := $(wildcard ???.txt)这条规则将会将当前目录下所有文件名长度为3，并以.txt为后缀的文件名赋值给变量SRCS。
-
~通配符：
~通配符代表当前用户的
home
目录，可以用来指定文件路径。例如，可以使用以下规则来指定当前用户的
home
目录：
$(HOME)/myprogram这条规则将会将当前用户的home目录路径和myprogram字符串拼接起来，从而得到一个完整的路径名，使得我们可以方便地引用home目录下的文件或路径。
变量
变量，可能是 Makefile 中使用最频繁的语法了，Makefile 支持变量赋值、多行变量和环境变量。另外，Makefile 还内置了一些特殊变量和自动化变量。
变量赋值 ：
Makefile 也可以像其他语言一样支持变量。在使用变量时，会像 shell 变量一样原地展开，然后再执行替换后的内容。
Makefile 可以通过变量声明来声明一个变量，变量在声明时需要赋予一个初值，比如
ROOT_PACKAGE=github.com/marmotedu/iam
。
引用变量时可以通过
$()
或者
${}
方式引用。我的建议是，用
$()
方式引用变量，例如
$(ROOT_PACKAGE)
，也建议整个 makefile 的变量引用方式保持一致。
变量会像 bash 变量一样，在使用它的地方展开。比如：
GO=go
build:
$(GO) build -v .展开后为：
GO=go
build:
go build -v .
Makefile 有四种的赋值方式：
=
最基本的赋值方法。
BASE_IMAGE = alpine:3.10注意：使用=赋值的时候，取值到的并非是程序依次执行的值，而是最终的值
A = a
B = $(A) b
A = c
B 最后的值为 c b，而不是 a b。也就是说，在用变量给变量赋值时，右边变量的取值，取的是最终的变量值。
和go一样，
:=
直接赋值，赋予当前位置的值。
A = a
B := $(A) b
A = c
B 最后的值为 a b。通过
:=
的赋值方式，可以避免
=
赋值带来的潜在的不一致。
?=
表示如果该变量没有被赋值，则赋予等号后的值。
例如：
PLATFORMS ?= linux_amd64 linux_arm64
+=
表示将等号后面的值添加到前面的变量上。
MAKEFLAGS += --no-print-directory
Makefile 还支持多行变量。可以通过 define 关键字设置多行变量，变量中允许换行。定义方式为：
define 变量名
endef
变量的内容可以包含函数、命令、文字或是其他变量。例如，我们可以定义一个
USAGE_OPTIONS
变量：
define USAGE_OPTIONS
Options:
DEBUG Whether to generate debug symbols. Default is 0.
BINS The binaries to build. Default is all of cmd.
V Set to 1 enable verbose build. Default is 0.
endefMakefile 还支持环境变量。在 Makefile 中，有两种环境变量，分别是 Makefile 预定义的环境变量和自定义的环境变量。
其中，自定义的环境变量可以覆盖 Makefile 预定义的环境变量。默认情况下，Makefile 中定义的环境变量只在当前 Makefile 有效，如果想向下层传递（Makefile 中调用另一个 Makefile），需要使用 export 关键字来声明。
...
export USAGE_OPTIONS
...此外，Makefile 还支持两种内置的变量：特殊变量和自动化变量。
特殊变量是 make 提前定义好的，可以在 makefile 中直接引用。特殊变量列表如下：
Makefile 还支持自动化变量。自动化变量可以提高我们编写 Makefile 的效率和质量。
自动化变量：
这时就可以用到自动化变量。所谓自动化变量，就是这种变量会把模式中所定义的一系列的文件自动地挨个取出，一直到所有符合模式的文件都取完为止。这种自动化变量只应出现在规则的命令中。Makefile 中支持的自动化变量见下表。
上面这些自动化变量中，
$*
是用得最多的。
$*
对于构造有关联的文件名是比较有效的。如果目标中没有模式的定义，那么
$*
也就不能被推导出。但是，如果目标文件的后缀是 make 所识别的，那么
$*
就是除了后缀的那一部分。例如：如果目标是
foo.c
，因为.c 是 make 所能识别的后缀名，所以
$*
的值就是 foo。
条件语句：
Makefile 也支持条件语句。这里先看一个示例。
下面的例子判断变量ROOT_PACKAGE是否为空，如果为空，则输出错误信息，不为空则打印变量值：
ifeq ($(ROOT_PACKAGE),)
$(error the variable ROOT_PACKAGE must be set prior to including golang.mk)
$(info the value of ROOT_PACKAGE is $(ROOT_PACKAGE))
endif条件语句的语法为：
# if ...
<conditional-directive>
<text-if-true>
endif
# if ... else ...
<conditional-directive>
<text-if-true>
<text-if-false>
endif例如，判断两个值是否相等：
ifeq 条件表达式
endif- ifeq 表示条件语句的开始，并指定一个条件表达式。表达式包含两个参数，参数之间用逗号分隔，并且表达式用圆括号括起来。
- else 表示条件表达式为假的情况。
- endif 表示一个条件语句的结束，任何一个条件表达式都应该以 endif 结束。
- 表示条件关键字，有 4 个关键字：ifeq、ifneq、ifdef、ifndef。
为了加深你的理解，我们分别来看下这 4 个关键字的例子。
ifeq：条件判断，判断是否相等。
ifeq (<arg1>, <arg2>)
ifeq '<arg1>' '<arg2>'
ifeq "<arg1>" "<arg2>"
ifeq "<arg1>" '<arg2>'
ifeq '<arg1>' "<arg2>"
比较 arg1 和 arg2 的值是否相同，如果相同则为真。也可以用 make 函数 / 变量替代 arg1 或 arg2，例如
ifeq ($(origin ROOT_DIR),undefined)
或
ifeq ($(ROOT_PACKAGE),)
。origin 函数会在之后专门讲函数的一讲中介绍到。
ifneq：条件判断，判断是否不相等。
ifneq (<arg1>, <arg2>)
ifneq '<arg1>' '<arg2>'
ifneq "<arg1>" "<arg2>"
ifneq "<arg1>" '<arg2>'
ifneq '<arg1>' "<arg2>"比较 arg1 和 arg2 的值是否不同，如果不同则为真。
ifdef：条件判断，判断变量是否已定义。
ifdef <variable-name>如果值非空，则表达式为真，否则为假。也可以是函数的返回值。
ifndef：条件判断，判断变量是否未定义。
ifndef <variable-name>如果值为空，则表达式为真，否则为假。也可以是函数的返回值。
函数
我们先来看下自定义函数。 make 解释器提供了一系列的函数供 Makefile 调用，这些函数是 Makefile 的预定义函数。我们可以通过 define 关键字来自定义一个函数。自定义函数的语法为：
define 函数名
endef
简单的一个案例如下：
define Foo
@echo "my name is $(0)"
@echo "param is $(1)"
endefdefine 本质上是定义一个多行变量，可以在 call 的作用下当作函数来使用，在其他位置使用只能作为多行变量来使用，例如：
var := $(call Foo)
new := $(Foo)
预定义函数：
再来看下预定义函数。 刚才提到，make 编译器也定义了很多函数，这些函数叫作预定义函数，调用语法和变量类似，语法为：
$(<function> <arguments>)
${<function> <arguments>}
<function>
是函数名，
<arguments>
是函数参数，参数间用逗号分割。函数的参数也可以是变量。
简单的一个案例如下：
PLATFORM = linux_amd64
GOOS := $(word 1, $(subst _, ,$(PLATFORM)))
上面的例子用到了两个函数：word 和 subst。word 函数有两个参数，1 和 subst 函数的输出。subst 函数将 PLATFORM 变量值中的
_
替换成空格（替换后的 PLATFORM 值为 linux amd64）。word 函数取 linux amd64 字符串中的第一个单词。所以最后 GOOS 的值为 linux。
Makefile 预定义函数能够帮助我们实现很多强大的功能，在编写 Makefile 的过程中，如果有功能需求，可以优先使用这些函数。如果你想使用这些函数，那就需要知道有哪些函数，以及它们实现的功能。
引入其他 Makefile
在 Makefile 中，我们可以通过关键字 include，把别的 makefile 包含进来，类似于 C 语言的#include，被包含的文件会插入在当前的位置。include 用法为include ，示例如下：
include scripts/make-rules/common.mk
include scripts/make-rules/golang.mkinclude 也可以包含通配符include scripts/make-rules/*。make 命令会按下面的顺序查找 makefile 文件：
- 如果是绝对或相对路径，就直接根据路径 include 进来。
-
如果 make 执行时，有
-I或--include-dir参数，那么 make 就会在这个参数所指定的目录下去找。 -
如果目录
<prefix>/include（一般是/usr/local/bin或/usr/include）存在的话，make 也会去找。
如果有文件没有找到，make 会生成一条警告信息，但不会马上出现致命错误，而是继续载入其他的文件。一旦完成 makefile 的读取，make 会再重试这些没有找到或是不能读取的文件。如果还是不行，make 才会出现一条致命错误信息。如果你想让
make
忽略那些无法读取的文件继续执行，可以在 i
n
clude 前加一个减号
-
，如
-include
。
设计Makefile结构
对于大型项目来说，需要管理的内容很多，所有管理功能都集成在一个 Makefile 中，可能会导致 Makefile 很大，难以阅读和维护，所以建议采用分层的设计方法， 根目录下的 Makefile 聚合所有的 Makefile 命令，具体实现则按功能分类，放在另外的 Makefile 中。
我们经常会在 Makefile 命令中集成 shell 脚本，但如果 shell 脚本过于复杂，也会导致 Makefile 内容过多，难以阅读和维护。并且在 Makefile 中集成复杂的 shell 脚本，编写体验也很差。对于这种情况， 可以将复杂的 shell 命令封装在 shell 脚本中，供 Makefile 直接调用，而一些简单的命令则可以直接集成在 Makefile 中。
推荐的 Makefile 结构：
在上面的 Makefile 组织方式中，根目录下的 Makefile 聚合了项目所有的管理功能，这些管理功能通过 Makefile 伪目标的方式实现。同时，还将这些伪目标进行分类，把相同类别的伪目标放在同一个 Makefile 中，这样可以使得 Makefile 更容易维护。对于复杂的命令，则编写成独立的 shell 脚本，并在 Makefile 命令中调用这些 shell 脚本。
举个例子，下面是 IAM 项目的 Makefile 组织结构：
├── Makefile
├── scripts
│ ├── gendoc.sh
│ ├── make-rules
│ │ ├── gen.mk
│ │ ├── golang.mk
│ │ ├── image.mk
│ │ └── ...
└── ...
├── Makefile
├── scripts
│ ├── gendoc.sh
│ ├── make-rules
│ │ ├── gen.mk
│ │ ├── golang.mk
│ │ ├── image.mk
│ │ └── ...
└── ...
我们将相同类别的操作统一放在
scripts/make-rules
目录下的 Makefile 文件中。
Makefile 的文件名参考分类命名
，例如
golang.mk
。最后，在
/Makefile
中 include 这些 Makefile。
需要使用include来获取头文件：
include是一种指令，用于将另一个文件中的规则和变量导入到当前的makefile中。这样做可以让你的makefile更加模块化，易于维护和重用。
注意和我们上面讲的模块化分配 Makefile 层级调用有些不一样。
下面是一个include的案例，假设我们有一个名为main.c的源文件，它需要链接一个名为libfoo.a的静态库文件。我们可以将这些规则和变量定义在一个名为Makefile.inc的文件中，然后在我们的主makefile中使用include指令将其导入。
CC = gcc
CFLAGS = -Wall -Werror -g
all: libfoo.a
libfoo.a: foo.o
ar rcs $@ $^
foo.o: foo.c foo.h
$(CC) $(CFLAGS) -c $<
clean:
rm -f *.o libfoo.a
主makefile文件：
include Makefile.inc
main: main.c libfoo.a
$(CC) $(CFLAGS) -o $@ $< -L. -lfoo
.PHONY: clean
clean:
$(MAKE) -C . -f Makefile.inc clean
rm -f main
go 语言Makefile 简单的一个案例如下：
# 定义变量
GOCMD=go
GOBUILD=$(GOCMD) build
GOCLEAN=$(GOCMD) clean
BINARY_NAME=myapp
BINARY_UNIX=$(BINARY_NAME)_unix
all: deps build
build:
$(GOBUILD) -o $(BINARY_NAME) -v
$(GOBUILD) -o $(BINARY_UNIX) -v
deps:
$(GOCMD) get -u http:// github.com/golang/dep/c md/dep
dep ensure
clean:
$(GOCLEAN)
rm -f $(BINARY_NAME)
rm -f $(BINARY_UNIX)
run:
$(GOBUILD) -o $(BINARY_NAME) -v ./...
./$(BINARY_NAME)
include docker.mk
在上面的示例中，最后一行include docker.mk引用了名为docker.mk的 Makefile 文件。这个文件中可能包含了一些 Docker 相关的命令，比如构建镜像、推送镜像等等。通过 include 指令，这些命令可以被自动引入到主 Makefile 文件中，从而实现更加高效和便捷的编译和构建。
需要注意的是，include 指令的作用是将被引入的 Makefile 文件的内容直接复制到主 Makefile 文件中。因此，如果引入的文件中定义了和主 Makefile 文件中相同的变量或者规则，会发生命名冲突。因此，在编写被引入的 Makefile 文件时，应该避免使用和主 Makefile 文件相同的变量和规则名。
为了跟 Makefile 的层级相匹配，
golang.mk
中的所有目标都按
go.xxx
这种方式命名。通过这种命名方式，我们可以很容易分辨出某个目标完成什么功能，放在什么文件里，这在复杂的 Makefile 中尤其有用。以下是 IAM 项目根目录下，Makefile 的内容摘录，你可以看一看，作为参考：
include scripts/make-rules/golang.mk
include scripts/make-rules/image.mk
include scripts/make-rules/gen.mk
include scripts/make-rules/...
## build: Build source code for host platform.
.PHONY: build
build:
@$(MAKE) go.build
## build.multiarch: Build source code for multiple platforms. See option PLATFORMS.
.PHONY: build.multiarch
build.multiarch:
@$(MAKE) go.build.multiarch
## image: Build docker images for host arch.
.PHONY: image
image:
@$(MAKE) image.build
## push: Build docker images for host arch and push images to registry.
.PHONY: push
push:
@$(MAKE) image.push
## ca: Generate CA files for all iam components.
.PHONY: ca
@$(MAKE) gen.ca另外，一个合理的 Makefile 结构应该具有前瞻性。也就是说，要在不改变现有结构的情况下，接纳后面的新功能。这就需要你整理好 Makefile 当前要实现的功能、即将要实现的功能和未来可能会实现的功能，然后基于这些功能，利用 Makefile 编程技巧，编写可扩展的 Makefile。
这里需要你注意：上面的 Makefile 通过
.PHONY
标识定义了大量的伪目标，定义伪目标一定要加
.PHONY
标识，否则当有同名的文件时，伪目标可能不会被执行。
掌握 Makefile 编写技巧
技巧 1：善用通配符和自动变量
Makefile 允许对目标进行类似正则运算的匹配，主要用到的通配符是%。通过使用通配符，可以使不同的目标使用相同的规则，从而使 Makefile 扩展性更强，也更简洁。
我们的 IAM 实战项目中，就大量使用了通配符
%
，例如：
go.build.%
、
ca.gen.%
、
deploy.run.%
、
tools.verify.%
、
tools.install.%
等。
这里，我们来看一个具体的例子，
tools.verify.%
（位于
scripts/make-rules/tools.mk
文件中）定义如下：
tools.verify.%:
@if ! which $* &>/dev/null; then $(MAKE) tools.install.$*; fi
make tools.verify.swagger
,
make tools.verify.mockgen
等均可以使用上面定义的规则，%分别代表了
swagger
和
mockgen
。
如果不使用
%
，则我们需要分别为
tools.verify.swagger
和
tools.verify.mockgen
定义规则，很麻烦，后面修改也困难。
另外，这里也能看出
tools.verify.%
这种命名方式的好处：tools 说明依赖的定义位于
scripts/make-rules/tools.mk
Makefile 中；verify说明
tools.verify.%
伪目标属于 verify 分类，主要用来验证工具是否安装。通过这种命名方式，你可以很容易地知道目标位于哪个 Makefile 文件中，以及想要完成的功能。
另外，上面的定义中还用到了自动变量
$*
，用来指代被匹配的值
swagger
、
mockgen
。
技巧 2：善用函数
Makefile 自带的函数能够帮助我们实现很多强大的功能。所以，在我们编写 Makefile 的过程中，如果有功能需求，可以优先使用这些函数。我把常用的函数以及它们实现的功能整理在了 Makefile 常用函数列表 中，你可以参考下。
IAM 的 Makefile 文件中大量使用了上述函数，如果你想查看这些函数的具体使用方法和场景，可以参考 IAM 项目的 Makefile 文件
make-rules
。
技巧 3：依赖需要用到的工具
如果 Makefile 某个目标的命令中用到了某个工具，可以将该工具放在目标的依赖中。这样，当执行该目标时，就可以指定检查系统是否安装该工具，如果没有安装则自动安装，从而实现更高程度的自动化。例如，
/Makefile
文件中，
format
伪目标，定义如下：
.PHONY: format
format: tools.verify.golines tools.verify.goimports
@echo "===========> Formating codes"
@$(FIND) -type f -name '*.go' | $(XARGS) gofmt -s -w
@$(FIND) -type f -name '*.go' | $(XARGS) goimports -w -local $(ROOT_PACKAGE)
@$(FIND) -type f -name '*.go' | $(XARGS) golines -w --max-len=120 --reformat-tags --shorten-comments --ignore-generated .
你可以看到，format 依赖
tools.verify.golines tools.verify.goimports
。我们再来看下
tools.verify.golines
的定义：
tools.verify.%:
@if ! which $* &>/dev/null; then $(MAKE) tools.install.$*; fi
再来看下
tools.install.$*
规则：
.PHONY: install.golines
install.golines:
@$(GO) get -u github.com/segmentio/golines
通过
tools.verify.%
规则定义，我们可以知道，
tools.verify.%
会先检查工具是否安装，如果没有安装，就会执行
tools.install.$*
来安装。如此一来，当我们执行
tools.verify.%
目标时，如果系统没有安装 golines 命令，就会自动调用go get安装，提高了 Makefile 的自动化程度。
技巧 4：把常用功能放在 /Makefile 中，不常用的放在分类 Makefile 中
一个项目，尤其是大型项目，有很多需要管理的地方，其中大部分都可以通过 Makefile 实现自动化操作。不过，为了保持
/Makefile
文件的整洁性，我们不能把所有的命令都添加在
/Makefile
文件中。
一个比较好的建议是，将常用功能放在 /Makefile 中，不常用的放在分类 Makefile 中，并在 /Makefile 中 include 这些分类 Makefile。
例如，IAM 项目的 /Makefile 集成了format、lint、test、build等常用命令，而将
gen.errcode.code、gen.errcode.doc
这类不常用的功能放在
scripts/make-rules/gen.mk
文件中。当然，我们也可以直接执行 make gen.errcode.code来执行gen.errcode.code伪目标。通过这种方式，既可以保证 /Makefile 的简洁、易维护，又可以通过make命令来运行伪目标，更加灵活。
技巧 5：编写可扩展的 Makefile
什么叫可扩展的 Makefile 呢？在我看来，可扩展的 Makefile 包含两层含义：
- 可以在不改变 Makefile 结构的情况下添加新功能。
- 扩展项目时，新功能可以自动纳入到 Makefile 现有逻辑中。
其中的第一点，我们可以通过设计合理的 Makefile 结构来实现。要实现第二点，就需要我们在编写 Makefile 时采用一定的技巧，例如多用通配符、自动变量、函数等。这里我们来看一个例子，可以让你更好地理解。
在我们 IAM 实战项目的golang.mk中，执行
make go.build
时能够构建
cmd/
目录下的所有组件，也就是说，当有新组件添加时，
make go.build
仍然能够构建新增的组件，这就实现了上面说的第二点。
具体实现方法如下：
COMMANDS ?= $(filter-out %.md, $(wildcard ${ROOT_DIR}/cmd/*))
BINS ?= $(foreach cmd,${COMMANDS},$(notdir ${cmd}))
.PHONY: go.build
go.build: go.build.verify $(addprefix go.build., $(addprefix $(PLATFORM)., $(BINS)))
.PHONY: go.build.%
go.build.%:
$(eval COMMAND := $(word 2,$(subst ., ,$*)))
$(eval PLATFORM := $(word 1,$(subst ., ,$*)))
$(eval OS := $(word 1,$(subst _, ,$(PLATFORM))))
$(eval ARCH := $(word 2,$(subst _, ,$(PLATFORM))))
@echo "===========> Building binary $(COMMAND) $(VERSION) for $(OS) $(ARCH)"
@mkdir -p $(OUTPUT_DIR)/platforms/$(OS)/$(ARCH)
@CGO_ENABLED=0 GOOS=$(OS) GOARCH=$(ARCH) $(GO) build $(GO_BUILD_FLAGS) -o $(OUTPUT_DIR)/platforms/$(OS)/$(ARCH)/$(COMMAND)$(GO_OUT_EXT) $(ROOT_PACKAGE)/cmd/$(COMMAND)
COMMANDS ?= $(filter-out %.md, $(wildcard ${ROOT_DIR}/cmd/*))
BINS ?= $(foreach cmd,${COMMANDS},$(notdir ${cmd}))
.PHONY: go.build
go.build: go.build.verify $(addprefix go.build., $(addprefix $(PLATFORM)., $(BINS)))
.PHONY: go.build.%
go.build.%:
$(eval COMMAND := $(word 2,$(subst ., ,$*)))
$(eval PLATFORM := $(word 1,$(subst ., ,$*)))
$(eval OS := $(word 1,$(subst _, ,$(PLATFORM))))
$(eval ARCH := $(word 2,$(subst _, ,$(PLATFORM))))
@echo "===========> Building binary $(COMMAND) $(VERSION) for $(OS) $(ARCH)"
@mkdir -p $(OUTPUT_DIR)/platforms/$(OS)/$(ARCH)
@CGO_ENABLED=0 GOOS=$(OS) GOARCH=$(ARCH) $(GO) build $(GO_BUILD_FLAGS) -o $(OUTPUT_DIR)/platforms/$(OS)/$(ARCH)/$(COMMAND)$(GO_OUT_EXT) $(ROOT_PACKAGE)/cmd/$(COMMAND)
当执行make go.build 时，会执行 go.build 的依赖
$(addprefix go.build., $(addprefix $(PLATFORM)., $(BINS))
) ,
addprefix
函数最终返回字符串
go.build.linux_amd64.iamctl go.build.linux_amd64.iam-authz-server go.build.linux_amd64.iam-apiserver ...
，这时候就会执行
go.build.%
伪目标。
在
go.build.%
伪目标中，通过 eval、word、subst 函数组合，算出了 COMMAND 的值
iamctl/iam-apiserver/iam-authz-server/...
，最终通过
$(ROOT_PACKAGE)/cmd/$(COMMAND)
定位到需要构建的组件的 main 函数所在目录。
上述实现中有两个技巧，你可以注意下。首先，通过
COMMANDS ?= $(filter-out %.md, $(wildcard ${ROOT_DIR}/cmd/*))
BINS ?= $(foreach cmd,${COMMANDS},$(notdir ${cmd}))获取到了 cmd/ 目录下的所有组件名。
接着，通过使用通配符和自动变量，自动匹配到
go.build.linux_amd64.iam-authz-server
这类伪目标并构建。
可以看到，想要编写一个可扩展的 Makefile，熟练掌握 Makefile 的用法是基础，更多的是需要我们动脑思考如何去编写 Makefile。
技巧 6：将所有输出存放在一个目录下，方便清理和查找
在执行 Makefile 的过程中，会输出各种各样的文件，例如 Go 编译后的二进制文件、测试覆盖率数据等，我建议你把这些文件统一放在一个目录下，方便后期的清理和查找。通常我们可以把它们放在
_output
这类目录下，这样清理时就很方便，只需要清理
_output
文件夹就可以，例如：
.PHONY: go.clean
go.clean:
@echo "===========> Cleaning all build output"
@-rm -vrf $(OUTPUT_DIR)
这里要注意，要用
-rm
，而不是rm，防止在没有
_output
目录时，执行
make go.clean
报错。
技巧 7：使用带层级的命名方式
通过使用带层级的命名方式，例如
tools.verify.swagger
，我们可以实现目标分组管理。这样做的好处有很多。首先，当 Makefile 有大量目标时，通过分组，我们可以更好地管理这些目标。其次，分组也能方便理解，可以通过组名一眼识别出该目标的功能类别。最后，这样做还可以大大减小目标重名的概率。
例如，IAM 项目的 Makefile 就大量采用了下面这种命名方式。
.PHONY: gen.run
gen.run: gen.clean gen.errcode gen.docgo
.PHONY: gen.errcode
gen.errcode: gen.errcode.code gen.errcode.doc
.PHONY: gen.errcode.code
gen.errcode.code: tools.verify.codegen
.PHONY: gen.errcode.doc
gen.errcode.doc: tools.verify.codegen
...
技巧 8：做好目标拆分
还有一个比较实用的技巧：我们要合理地拆分目标。比如，我们可以将安装工具拆分成两个目标：验证工具是否已安装和安装工具。通过这种方式，可以给我们的 Makefile 带来更大的灵活性。例如：我们可以根据需要选择性地执行其中一个操作，也可以两个操作一起执行。
这里来看一个例子：
gen.errcode.code: tools.verify.codegen
tools.verify.%:
@if ! which $* &>/dev/null; then $(MAKE) tools.install.$*; fi
.PHONY: install.codegen
install.codegen:
@$(GO) install ${ROOT_DIR}/tools/codegen/codegen.go
上面的 Makefile 中，
gen.errcode.code
依赖了
tools.verify.codegen
，
tools.verify.codegen
会先检查 codegen 命令是否存在，如果不存在，再调用 install.codegen 来安装 codegen 工具。
如果我们的 Makefile 设计是：
gen.errcode.code: install.codegen那每次执行 gen.errcode.code 都要重新安装 codegen 命令，这种操作是不必要的，还会导致 make gen.errcode.code 执行很慢。
技巧 9：设置 OPTIONS
编写 Makefile 时，我们还需要把一些可变的功能通过 OPTIONS 来控制。为了帮助你理解，这里还是拿 IAM 项目的 Makefile 来举例。
假设我们需要通过一个选项 V ，来控制是否需要在执行 Makefile 时打印详细的信息。这可以通过下面的步骤来实现。
首先，在
/Makefile
中定义
USAGE_OPTIONS
。定义
USAGE_OPTIONS
可以使开发者在执行 make help 后感知到此 OPTION，并根据需要进行设置。
define USAGE_OPTIONS
Options:
BINS The binaries to build. Default is all of cmd.
V Set to 1 enable verbose build. Default is 0.
endef
export USAGE_OPTIONS
接着，在
scripts/make-rules/common.mk
文件中，我们通过判断有没有设置 V 选项，来选择不同的行为：
ifndef V
MAKEFLAGS += --no-print-directory
endif当然，我们还可以通过下面的方法来使用 V ：
ifeq ($(origin V), undefined)
MAKEFLAGS += --no-print-directory
endif上面，我介绍了 V OPTION，我们在 Makefile 中通过判断有没有定义 V ，来执行不同的操作。其实还有一种 OPTION，这种 OPTION 的值我们在 Makefile 中是直接使用的，例如BINS。针对这种 OPTION，我们可以通过以下方式来使用：
BINS ?= $(foreach cmd,${COMMANDS},$(notdir ${cmd}))
go.build: go.build.verify $(addprefix go.build., $(addprefix $(PLATFORM)., $(BINS)))也就是说，通过 ?= 来判断 BINS 变量有没有被赋值，如果没有，则赋予等号后的值。接下来，就可以在 Makefile 规则中使用它。
技巧 10：定义环境变量
我们可以在 Makefile 中定义一些环境变量，例如：
GO := go
GO_SUPPORTED_VERSIONS ?= 1.13|1.14|1.15|1.16|1.17
GO_LDFLAGS += -X $(VERSION_PACKAGE).GitVersion=$(VERSION) \
-X $(VERSION_PACKAGE).GitCommit=$(GIT_COMMIT) \
-X $(VERSION_PACKAGE).GitTreeState=$(GIT_TREE_STATE) \
-X $(VERSION_PACKAGE).BuildDate=$(shell date -u +'%Y-%m-%dT%H:%M:%SZ')
ifneq ($(DLV),)
GO_BUILD_FLAGS += -gcflags "all=-N -l"
LDFLAGS = ""
endif
GO_BUILD_FLAGS += -tags=jsoniter -ldflags "$(GO_LDFLAGS)"