2019-06-27 14:24:16 +00:00
|
|
|
export GO111MODULE=off
|
|
|
|
|
|
2017-11-01 15:24:59 +00:00
|
|
|
GO ?= go
|
2019-06-07 05:46:41 +00:00
|
|
|
DESTDIR ?=
|
2019-07-02 18:58:54 +00:00
|
|
|
EPOCH_TEST_COMMIT ?= 55e028a12ee003e057c65e376fe4b723d28ae52e
|
2017-11-03 19:37:22 +00:00
|
|
|
HEAD ?= HEAD
|
2018-03-17 14:52:54 +00:00
|
|
|
CHANGELOG_BASE ?= HEAD~
|
|
|
|
|
CHANGELOG_TARGET ?= HEAD
|
2018-08-16 10:41:15 +00:00
|
|
|
PROJECT := github.com/containers/libpod
|
2018-12-12 12:57:18 +00:00
|
|
|
GIT_BASE_BRANCH ?= origin/master
|
Makefile: Use ?= for shell variables (ISODATE, etc.)
Previously, Make would execute these shell commands even if we didn't
need the resulting variable. With ?='s recursive expansion [1], we
only expand the variable when it's consumed. For example, the ISODATE
variable is only needed in the recipe for the changelog target, so
most Make invocations won't need the value, and the computation is
just making whatever Make actually is doing slower.
I've shifted the GIT_COMMIT and BUILD_INFO values over to
LDFLAGS_PODMAN, because the test/*/* targets don't care about those.
I've also moved the Go-specific -ldflags from the variables into the
recipes themselves, because callers probably expect C semantics for
LDFLAGS and not Go's wrapper. That means that there's no longer a
need for the LDFLAGS/BASE_LDFLAGS separation, so I'm just using
LDFLAGS (and LDFLAGS_PODMAN) now. That reduces the declared variables
to just LDFLAGS_PODMAN, so I've shifted that declaration up to get it
closer to its GIT_COMMIT and BUILD_INFO precursors.
[1]: https://www.gnu.org/software/make/manual/html_node/Setting.html
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #777
Approved by: rhatdan
2018-05-15 23:27:07 +00:00
|
|
|
GIT_BRANCH ?= $(shell git rev-parse --abbrev-ref HEAD 2>/dev/null)
|
|
|
|
|
GIT_BRANCH_CLEAN ?= $(shell echo $(GIT_BRANCH) | sed -e "s/[^[:alnum:]]/-/g")
|
|
|
|
|
LIBPOD_IMAGE ?= libpod_dev$(if $(GIT_BRANCH_CLEAN),:$(GIT_BRANCH_CLEAN))
|
2017-11-02 19:31:21 +00:00
|
|
|
LIBPOD_INSTANCE := libpod_dev
|
2019-06-07 05:46:41 +00:00
|
|
|
PREFIX ?= /usr/local
|
2017-11-01 15:24:59 +00:00
|
|
|
BINDIR ?= ${PREFIX}/bin
|
|
|
|
|
LIBEXECDIR ?= ${PREFIX}/libexec
|
|
|
|
|
MANDIR ?= ${PREFIX}/share/man
|
2018-03-01 20:33:04 +00:00
|
|
|
SHAREDIR_CONTAINERS ?= ${PREFIX}/share/containers
|
2019-06-07 05:46:41 +00:00
|
|
|
ETCDIR ?= /etc
|
2018-05-18 20:28:51 +00:00
|
|
|
TMPFILESDIR ?= ${PREFIX}/lib/tmpfiles.d
|
2018-03-26 14:39:14 +00:00
|
|
|
SYSTEMDDIR ?= ${PREFIX}/lib/systemd/system
|
2019-07-01 15:29:09 +00:00
|
|
|
BUILDFLAGS ?=
|
2019-05-08 06:49:08 +00:00
|
|
|
BUILDTAGS ?= \
|
|
|
|
|
$(shell hack/apparmor_tag.sh) \
|
|
|
|
|
$(shell hack/btrfs_installed_tag.sh) \
|
|
|
|
|
$(shell hack/btrfs_tag.sh) \
|
|
|
|
|
$(shell hack/ostree_tag.sh) \
|
|
|
|
|
$(shell hack/selinux_tag.sh) \
|
|
|
|
|
$(shell hack/systemd_tag.sh) \
|
|
|
|
|
exclude_graphdriver_devicemapper \
|
|
|
|
|
seccomp \
|
|
|
|
|
varlink
|
|
|
|
|
|
|
|
|
|
ifeq (,$(findstring systemd,$(BUILDTAGS)))
|
|
|
|
|
$(warning \
|
|
|
|
|
Podman is being compiled without the systemd build tag.\
|
|
|
|
|
Install libsystemd for journald support)
|
|
|
|
|
endif
|
|
|
|
|
|
2018-06-29 21:47:53 +00:00
|
|
|
BUILDTAGS_CROSS ?= containers_image_openpgp containers_image_ostree_stub exclude_graphdriver_btrfs exclude_graphdriver_devicemapper exclude_graphdriver_overlay
|
2018-06-22 13:56:08 +00:00
|
|
|
ifneq (,$(findstring varlink,$(BUILDTAGS)))
|
2018-08-02 13:58:59 +00:00
|
|
|
PODMAN_VARLINK_DEPENDENCIES = cmd/podman/varlink/iopodman.go
|
2018-06-22 13:56:08 +00:00
|
|
|
endif
|
2018-11-02 23:28:31 +00:00
|
|
|
CONTAINER_RUNTIME := $(shell command -v podman 2> /dev/null || echo docker)
|
2019-02-05 13:52:03 +00:00
|
|
|
OCI_RUNTIME ?= ""
|
2018-06-22 13:56:08 +00:00
|
|
|
|
2017-11-01 15:24:59 +00:00
|
|
|
BASHINSTALLDIR=${PREFIX}/share/bash-completion/completions
|
2019-03-01 22:39:51 +00:00
|
|
|
ZSHINSTALLDIR=${PREFIX}/share/zsh/site-functions
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
|
SELINUXOPT ?= $(shell test -x /usr/sbin/selinuxenabled && selinuxenabled && echo -Z)
|
|
|
|
|
|
Makefile: Use ?= for shell variables (ISODATE, etc.)
Previously, Make would execute these shell commands even if we didn't
need the resulting variable. With ?='s recursive expansion [1], we
only expand the variable when it's consumed. For example, the ISODATE
variable is only needed in the recipe for the changelog target, so
most Make invocations won't need the value, and the computation is
just making whatever Make actually is doing slower.
I've shifted the GIT_COMMIT and BUILD_INFO values over to
LDFLAGS_PODMAN, because the test/*/* targets don't care about those.
I've also moved the Go-specific -ldflags from the variables into the
recipes themselves, because callers probably expect C semantics for
LDFLAGS and not Go's wrapper. That means that there's no longer a
need for the LDFLAGS/BASE_LDFLAGS separation, so I'm just using
LDFLAGS (and LDFLAGS_PODMAN) now. That reduces the declared variables
to just LDFLAGS_PODMAN, so I've shifted that declaration up to get it
closer to its GIT_COMMIT and BUILD_INFO precursors.
[1]: https://www.gnu.org/software/make/manual/html_node/Setting.html
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #777
Approved by: rhatdan
2018-05-15 23:27:07 +00:00
|
|
|
COMMIT_NO ?= $(shell git rev-parse HEAD 2> /dev/null || true)
|
2019-02-04 17:37:11 +00:00
|
|
|
GIT_COMMIT ?= $(if $(shell git status --porcelain --untracked-files=no),${COMMIT_NO}-dirty,${COMMIT_NO})
|
2019-06-20 21:14:18 +00:00
|
|
|
DATE_FMT = %s
|
|
|
|
|
ifdef SOURCE_DATE_EPOCH
|
|
|
|
|
BUILD_INFO ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "+$(DATE_FMT)" 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "+$(DATE_FMT)" 2>/dev/null || date -u "+$(DATE_FMT)")
|
|
|
|
|
ISODATE ?= $(shell date -d "@$(SOURCE_DATE_EPOCH)" --iso-8601)
|
|
|
|
|
else
|
|
|
|
|
BUILD_INFO ?= $(shell date "+$(DATE_FMT)")
|
|
|
|
|
ISODATE ?= $(shell date --iso-8601)
|
|
|
|
|
endif
|
2018-10-30 22:55:48 +00:00
|
|
|
LIBPOD := ${PROJECT}/libpod
|
2019-06-20 21:17:53 +00:00
|
|
|
GCFLAGS ?= all=-trimpath=${PWD}
|
|
|
|
|
ASMFLAGS ?= all=-trimpath=${PWD}
|
2019-06-07 05:46:41 +00:00
|
|
|
LDFLAGS_PODMAN ?= $(LDFLAGS) \
|
|
|
|
|
-X $(LIBPOD).gitCommit=$(GIT_COMMIT) \
|
|
|
|
|
-X $(LIBPOD).buildInfo=$(BUILD_INFO) \
|
|
|
|
|
-X $(LIBPOD).installPrefix=$(PREFIX) \
|
|
|
|
|
-X $(LIBPOD).etcDir=$(ETCDIR)
|
2019-02-01 02:26:15 +00:00
|
|
|
#Update to LIBSECCOMP_COMMIT should reflect in Dockerfile too.
|
2018-04-25 18:26:52 +00:00
|
|
|
LIBSECCOMP_COMMIT := release-2.3
|
2019-02-05 18:22:42 +00:00
|
|
|
# Rarely if ever should integration tests take more than 50min,
|
|
|
|
|
# caller may override in special circumstances if needed.
|
2019-03-04 18:18:10 +00:00
|
|
|
GINKGOTIMEOUT ?= -timeout=90m
|
2019-02-05 18:22:42 +00:00
|
|
|
|
2019-05-10 23:02:01 +00:00
|
|
|
RELEASE_VERSION ?= $(shell git fetch --tags && git describe HEAD 2> /dev/null)
|
2019-07-01 18:52:55 +00:00
|
|
|
RELEASE_NUMBER ?= $(shell echo $(RELEASE_VERSION) | sed 's/-.*//')
|
2019-05-10 23:02:01 +00:00
|
|
|
RELEASE_DIST ?= $(shell ( source /etc/os-release; echo $$ID ))
|
|
|
|
|
RELEASE_DIST_VER ?= $(shell ( source /etc/os-release; echo $$VERSION_ID | cut -d '.' -f 1))
|
|
|
|
|
RELEASE_ARCH ?= $(shell go env GOARCH 2> /dev/null)
|
|
|
|
|
RELEASE_BASENAME := $(shell basename $(PROJECT))
|
|
|
|
|
|
2019-07-01 18:52:55 +00:00
|
|
|
|
2017-11-01 15:24:59 +00:00
|
|
|
# If GOPATH not specified, use one in the local directory
|
|
|
|
|
ifeq ($(GOPATH),)
|
|
|
|
|
export GOPATH := $(CURDIR)/_output
|
|
|
|
|
unexport GOBIN
|
|
|
|
|
endif
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
FIRST_GOPATH := $(firstword $(subst :, ,$(GOPATH)))
|
|
|
|
|
GOPKGDIR := $(FIRST_GOPATH)/src/$(PROJECT)
|
|
|
|
|
GOPKGBASEDIR ?= $(shell dirname "$(GOPKGDIR)")
|
|
|
|
|
|
2018-05-21 15:06:28 +00:00
|
|
|
GOBIN := $(shell $(GO) env GOBIN)
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
ifeq ($(GOBIN),)
|
|
|
|
|
GOBIN := $(FIRST_GOPATH)/bin
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
GOMD2MAN ?= $(shell command -v go-md2man || echo '$(GOBIN)/go-md2man')
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2017-11-03 19:37:22 +00:00
|
|
|
BOX="fedora_atomic"
|
|
|
|
|
|
2018-06-29 21:47:53 +00:00
|
|
|
CROSS_BUILD_TARGETS := \
|
|
|
|
|
bin/podman.cross.darwin.amd64 \
|
|
|
|
|
bin/podman.cross.linux.amd64
|
|
|
|
|
|
2017-11-01 15:29:12 +00:00
|
|
|
all: binaries docs
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
|
default: help
|
|
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
define PRINT_HELP_PYSCRIPT
|
|
|
|
|
import re, sys
|
|
|
|
|
|
|
|
|
|
print("Usage: make <target>")
|
|
|
|
|
cmds = {}
|
|
|
|
|
for line in sys.stdin:
|
|
|
|
|
match = re.match(r'^([a-zA-Z_-]+):.*?## (.*)$$', line)
|
|
|
|
|
if match:
|
|
|
|
|
target, help = match.groups()
|
|
|
|
|
cmds.update({target: help})
|
|
|
|
|
for cmd in sorted(cmds):
|
|
|
|
|
print(" * '%s' - %s" % (cmd, cmds[cmd]))
|
|
|
|
|
endef
|
|
|
|
|
export PRINT_HELP_PYSCRIPT
|
|
|
|
|
|
2017-11-01 15:24:59 +00:00
|
|
|
help:
|
2019-02-06 17:27:00 +00:00
|
|
|
@python -c "$$PRINT_HELP_PYSCRIPT" < $(MAKEFILE_LIST)
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
|
.gopathok:
|
|
|
|
|
ifeq ("$(wildcard $(GOPKGDIR))","")
|
|
|
|
|
mkdir -p "$(GOPKGBASEDIR)"
|
2019-07-17 23:18:26 +00:00
|
|
|
ln -sfnT "$(CURDIR)" "$(GOPKGDIR)"
|
|
|
|
|
ln -sfnT "$(CURDIR)/vendor/github.com/varlink" "$(FIRST_GOPATH)/src/github.com/varlink"
|
2017-11-01 15:24:59 +00:00
|
|
|
endif
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
touch $@
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
lint: .gopathok varlink_generate ## Execute the source code linter
|
2017-11-01 15:24:59 +00:00
|
|
|
@echo "checking lint"
|
|
|
|
|
@./.tool/lint
|
|
|
|
|
|
2019-07-22 18:08:06 +00:00
|
|
|
golangci-lint: .gopathok varlink_generate .install.golangci-lint
|
|
|
|
|
$(GOBIN)/golangci-lint run --tests=false
|
|
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
gofmt: ## Verify the source code gofmt
|
2018-07-02 15:45:06 +00:00
|
|
|
find . -name '*.go' ! -path './vendor/*' -exec gofmt -s -w {} \+
|
|
|
|
|
git diff --exit-code
|
2017-12-12 18:40:20 +00:00
|
|
|
|
2017-11-01 15:24:59 +00:00
|
|
|
test/checkseccomp/checkseccomp: .gopathok $(wildcard test/checkseccomp/*.go)
|
Makefile: Use ?= for shell variables (ISODATE, etc.)
Previously, Make would execute these shell commands even if we didn't
need the resulting variable. With ?='s recursive expansion [1], we
only expand the variable when it's consumed. For example, the ISODATE
variable is only needed in the recipe for the changelog target, so
most Make invocations won't need the value, and the computation is
just making whatever Make actually is doing slower.
I've shifted the GIT_COMMIT and BUILD_INFO values over to
LDFLAGS_PODMAN, because the test/*/* targets don't care about those.
I've also moved the Go-specific -ldflags from the variables into the
recipes themselves, because callers probably expect C semantics for
LDFLAGS and not Go's wrapper. That means that there's no longer a
need for the LDFLAGS/BASE_LDFLAGS separation, so I'm just using
LDFLAGS (and LDFLAGS_PODMAN) now. That reduces the declared variables
to just LDFLAGS_PODMAN, so I've shifted that declaration up to get it
closer to its GIT_COMMIT and BUILD_INFO precursors.
[1]: https://www.gnu.org/software/make/manual/html_node/Setting.html
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #777
Approved by: rhatdan
2018-05-15 23:27:07 +00:00
|
|
|
$(GO) build -ldflags '$(LDFLAGS)' -tags "$(BUILDTAGS) containers_image_ostree_stub" -o $@ $(PROJECT)/test/checkseccomp
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2018-10-29 06:56:07 +00:00
|
|
|
test/goecho/goecho: .gopathok $(wildcard test/goecho/*.go)
|
|
|
|
|
$(GO) build -ldflags '$(LDFLAGS)' -o $@ $(PROJECT)/test/goecho
|
|
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
podman: .gopathok $(PODMAN_VARLINK_DEPENDENCIES) ## Build with podman
|
2019-07-01 15:29:09 +00:00
|
|
|
$(GO) build $(BUILDFLAGS) -gcflags '$(GCFLAGS)' -asmflags '$(ASMFLAGS)' -ldflags '$(LDFLAGS_PODMAN)' -tags "$(BUILDTAGS)" -o bin/$@ $(PROJECT)/cmd/podman
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
podman-remote: .gopathok $(PODMAN_VARLINK_DEPENDENCIES) ## Build with podman on remote environment
|
2019-07-01 15:29:09 +00:00
|
|
|
$(GO) build $(BUILDFLAGS) -gcflags '$(GCFLAGS)' -asmflags '$(ASMFLAGS)' -ldflags '$(LDFLAGS_PODMAN)' -tags "$(BUILDTAGS) remoteclient" -o bin/$@ $(PROJECT)/cmd/podman
|
2019-01-02 20:56:19 +00:00
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
podman-remote-darwin: .gopathok $(PODMAN_VARLINK_DEPENDENCIES) ## Build with podman on remote OSX environment
|
2019-05-10 23:02:01 +00:00
|
|
|
CGO_ENABLED=0 GOOS=darwin $(GO) build -gcflags '$(GCFLAGS)' -asmflags '$(ASMFLAGS)' -ldflags '$(LDFLAGS_PODMAN)' -tags "remoteclient containers_image_openpgp exclude_graphdriver_devicemapper" -o bin/$@ $(PROJECT)/cmd/podman
|
2019-01-10 18:15:33 +00:00
|
|
|
|
2019-04-22 21:01:31 +00:00
|
|
|
podman-remote-windows: .gopathok $(PODMAN_VARLINK_DEPENDENCIES) ## Build with podman for a remote windows environment
|
2019-05-10 23:02:01 +00:00
|
|
|
CGO_ENABLED=0 GOOS=windows $(GO) build -gcflags '$(GCFLAGS)' -asmflags '$(ASMFLAGS)' -ldflags '$(LDFLAGS_PODMAN)' -tags "remoteclient containers_image_openpgp exclude_graphdriver_devicemapper" -o bin/$@.exe $(PROJECT)/cmd/podman
|
2019-04-22 21:01:31 +00:00
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
local-cross: $(CROSS_BUILD_TARGETS) ## Cross local compilation
|
2018-06-29 21:47:53 +00:00
|
|
|
|
|
|
|
|
bin/podman.cross.%: .gopathok
|
|
|
|
|
TARGET="$*"; \
|
|
|
|
|
GOOS="$${TARGET%%.*}" \
|
|
|
|
|
GOARCH="$${TARGET##*.}" \
|
2019-06-20 21:17:53 +00:00
|
|
|
$(GO) build -gcflags '$(GCFLAGS)' -asmflags '$(ASMFLAGS)' -ldflags '$(LDFLAGS_PODMAN)' -tags '$(BUILDTAGS_CROSS)' -o "$@" $(PROJECT)/cmd/podman
|
2018-06-20 18:23:24 +00:00
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
clean: ## Clean artifacts
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
rm -rf \
|
|
|
|
|
.gopathok \
|
|
|
|
|
_output \
|
2019-05-10 23:02:01 +00:00
|
|
|
podman*.zip \
|
2019-07-01 18:52:55 +00:00
|
|
|
podman*.tar.gz \
|
2018-06-29 21:47:53 +00:00
|
|
|
bin \
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
build \
|
2019-07-01 18:52:55 +00:00
|
|
|
docs/remote \
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
test/checkseccomp/checkseccomp \
|
2018-10-29 06:56:07 +00:00
|
|
|
test/goecho/goecho \
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
test/testdata/redis-image \
|
2018-08-02 13:58:59 +00:00
|
|
|
cmd/podman/varlink/iopodman.go \
|
2018-08-20 18:56:22 +00:00
|
|
|
libpod/container_ffjson.go \
|
|
|
|
|
libpod/pod_ffjson.go \
|
2018-08-22 13:12:40 +00:00
|
|
|
libpod/container_easyjson.go \
|
|
|
|
|
libpod/pod_easyjson.go \
|
2018-07-13 02:26:14 +00:00
|
|
|
$(MANPAGES) ||:
|
2017-11-01 15:24:59 +00:00
|
|
|
find . -name \*~ -delete
|
|
|
|
|
find . -name \#\* -delete
|
|
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
libpodimage: ## Build the libpod image
|
2018-10-23 21:36:35 +00:00
|
|
|
${CONTAINER_RUNTIME} build -t ${LIBPOD_IMAGE} .
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2017-11-02 19:31:21 +00:00
|
|
|
dbuild: libpodimage
|
2018-10-23 21:36:35 +00:00
|
|
|
${CONTAINER_RUNTIME} run --name=${LIBPOD_INSTANCE} --privileged -v ${PWD}:/go/src/${PROJECT} --rm ${LIBPOD_IMAGE} make all
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2019-04-19 02:41:37 +00:00
|
|
|
dbuild-podman-remote: libpodimage
|
|
|
|
|
${CONTAINER_RUNTIME} run --name=${LIBPOD_INSTANCE} --privileged -v ${PWD}:/go/src/${PROJECT} --rm ${LIBPOD_IMAGE} go build -ldflags '$(LDFLAGS_PODMAN)' -tags "$(BUILDTAGS) remoteclient" -o bin/podman-remote $(PROJECT)/cmd/podman
|
|
|
|
|
|
|
|
|
|
dbuild-podman-remote-darwin: libpodimage
|
|
|
|
|
${CONTAINER_RUNTIME} run --name=${LIBPOD_INSTANCE} --privileged -v ${PWD}:/go/src/${PROJECT} --rm ${LIBPOD_IMAGE} env GOOS=darwin go build -ldflags '$(LDFLAGS_PODMAN)' -tags "remoteclient containers_image_openpgp exclude_graphdriver_devicemapper" -o bin/podman-remote-darwin $(PROJECT)/cmd/podman
|
|
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
test: libpodimage ## Run tests on built image
|
2019-02-05 13:52:03 +00:00
|
|
|
${CONTAINER_RUNTIME} run -e STORAGE_OPTIONS="--storage-driver=vfs" -e TESTFLAGS -e OCI_RUNTIME -e CGROUP_MANAGER=cgroupfs -e TRAVIS -t --privileged --rm -v ${CURDIR}:/go/src/${PROJECT} ${LIBPOD_IMAGE} make clean all localunit install.catatonit localintegration
|
2018-03-07 15:14:17 +00:00
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
integration: libpodimage ## Execute integration tests
|
2019-02-05 13:52:03 +00:00
|
|
|
${CONTAINER_RUNTIME} run -e STORAGE_OPTIONS="--storage-driver=vfs" -e TESTFLAGS -e OCI_RUNTIME -e CGROUP_MANAGER=cgroupfs -e TRAVIS -t --privileged --rm -v ${CURDIR}:/go/src/${PROJECT} ${LIBPOD_IMAGE} make clean all install.catatonit localintegration
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2018-01-24 14:45:55 +00:00
|
|
|
integration.fedora:
|
|
|
|
|
DIST=Fedora sh .papr_prepare.sh
|
2018-02-09 18:31:47 +00:00
|
|
|
|
|
|
|
|
integration.centos:
|
|
|
|
|
DIST=CentOS sh .papr_prepare.sh
|
|
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
shell: libpodimage ## Run the built image and attach a shell
|
2019-02-05 13:52:03 +00:00
|
|
|
${CONTAINER_RUNTIME} run -e STORAGE_OPTIONS="--storage-driver=vfs" -e CGROUP_MANAGER=cgroupfs -e TESTFLAGS -e OCI_RUNTIME -e TRAVIS -it --privileged --rm -v ${CURDIR}:/go/src/${PROJECT} ${LIBPOD_IMAGE} sh
|
2018-03-13 15:36:40 +00:00
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
testunit: libpodimage ## Run unittest on the built image
|
2019-02-05 13:52:03 +00:00
|
|
|
${CONTAINER_RUNTIME} run -e STORAGE_OPTIONS="--storage-driver=vfs" -e TESTFLAGS -e CGROUP_MANAGER=cgroupfs -e OCI_RUNTIME -e TRAVIS -t --privileged --rm -v ${CURDIR}:/go/src/${PROJECT} ${LIBPOD_IMAGE} make localunit
|
2018-03-07 15:14:17 +00:00
|
|
|
|
2018-10-29 06:56:07 +00:00
|
|
|
localunit: test/goecho/goecho varlink_generate
|
2019-04-03 10:32:49 +00:00
|
|
|
ginkgo \
|
|
|
|
|
-r \
|
|
|
|
|
--skipPackage test/e2e,pkg/apparmor \
|
|
|
|
|
--cover \
|
|
|
|
|
--covermode atomic \
|
|
|
|
|
--tags "$(BUILDTAGS)" \
|
|
|
|
|
--succinct
|
2018-11-07 14:12:15 +00:00
|
|
|
$(MAKE) -C contrib/cirrus/packer test
|
2019-05-02 11:49:50 +00:00
|
|
|
./contrib/cirrus/lib.sh.t
|
2019-07-31 13:48:14 +00:00
|
|
|
./contrib/cirrus/cirrus_yaml_test.py
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2018-01-24 14:45:55 +00:00
|
|
|
ginkgo:
|
2019-05-14 20:41:01 +00:00
|
|
|
ginkgo -v -tags "$(BUILDTAGS)" $(GINKGOTIMEOUT) -cover -flakeAttempts 3 -progress -trace -noColor -nodes 3 -debug test/e2e/.
|
2018-01-24 14:45:55 +00:00
|
|
|
|
2019-01-14 19:23:13 +00:00
|
|
|
ginkgo-remote:
|
2019-02-05 18:22:42 +00:00
|
|
|
ginkgo -v -tags "$(BUILDTAGS) remoteclient" $(GINKGOTIMEOUT) -cover -flakeAttempts 3 -progress -trace -noColor test/e2e/.
|
2019-01-14 19:23:13 +00:00
|
|
|
|
2019-05-08 20:21:33 +00:00
|
|
|
localintegration: varlink_generate test-binaries ginkgo
|
|
|
|
|
|
|
|
|
|
remoteintegration: varlink_generate test-binaries ginkgo-remote
|
2018-05-15 01:01:08 +00:00
|
|
|
|
2019-04-15 18:49:53 +00:00
|
|
|
localsystem:
|
2019-07-09 18:03:35 +00:00
|
|
|
# Wipe existing config, database, and cache: start with clean slate.
|
|
|
|
|
$(RM) -rf ${HOME}/.local/share/containers ${HOME}/.config/containers
|
2019-04-15 18:49:53 +00:00
|
|
|
if timeout -v 1 true; then PODMAN=./bin/podman bats test/system/; else echo "Skipping localsystem: 'timeout -v' unavailable'"; fi
|
|
|
|
|
|
|
|
|
|
remotesystem:
|
|
|
|
|
@echo "remotesystem - unimplemented"
|
2018-10-29 06:56:23 +00:00
|
|
|
|
2019-02-06 18:57:46 +00:00
|
|
|
system.test-binary: .install.ginkgo
|
2018-11-16 03:19:37 +00:00
|
|
|
$(GO) test -c ./test/system
|
|
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
perftest: ## Build perf tests
|
2018-10-26 05:47:52 +00:00
|
|
|
$ cd contrib/perftest;go build
|
|
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
run-perftest: perftest ## Build and run perf tests
|
2018-10-26 05:47:52 +00:00
|
|
|
$ contrib/perftest/perftest
|
|
|
|
|
|
2017-11-03 19:37:22 +00:00
|
|
|
vagrant-check:
|
|
|
|
|
BOX=$(BOX) sh ./vagrant.sh
|
|
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
binaries: varlink_generate podman podman-remote ## Build podman
|
2017-11-02 19:31:21 +00:00
|
|
|
|
2019-05-10 23:02:01 +00:00
|
|
|
# Zip archives are supported on all platforms + allows embedding metadata
|
|
|
|
|
podman.zip: binaries docs
|
|
|
|
|
$(eval TMPDIR := $(shell mktemp -d -p '' $@_XXXX))
|
|
|
|
|
test -n "$(TMPDIR)"
|
|
|
|
|
$(MAKE) install "DESTDIR=$(TMPDIR)" "PREFIX=$(TMPDIR)/usr"
|
|
|
|
|
# Encoded RELEASE_INFO format depended upon by CI tooling
|
|
|
|
|
# X-RELEASE-INFO format depended upon by CI tooling
|
|
|
|
|
cd "$(TMPDIR)" && echo \
|
|
|
|
|
"X-RELEASE-INFO: $(RELEASE_BASENAME) $(RELEASE_VERSION) $(RELEASE_DIST) $(RELEASE_DIST_VER) $(RELEASE_ARCH)" | \
|
|
|
|
|
zip --recurse-paths --archive-comment "$(CURDIR)/$@" "./"
|
|
|
|
|
-rm -rf "$(TMPDIR)"
|
|
|
|
|
|
|
|
|
|
podman-remote-%.zip: podman-remote-%
|
|
|
|
|
# Don't label darwin/windows cros-compiles with local distribution & version
|
|
|
|
|
echo "X-RELEASE-INFO: podman-remote $(RELEASE_VERSION) $* cc $(RELEASE_ARCH)" | \
|
|
|
|
|
zip --archive-comment "$(CURDIR)/$@" ./bin/$<*
|
|
|
|
|
|
2018-12-22 13:59:43 +00:00
|
|
|
install.catatonit:
|
|
|
|
|
./hack/install_catatonit.sh
|
|
|
|
|
|
2019-02-09 02:09:04 +00:00
|
|
|
test-binaries: test/checkseccomp/checkseccomp test/goecho/goecho install.catatonit
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2018-05-15 16:26:38 +00:00
|
|
|
MANPAGES_MD ?= $(wildcard docs/*.md pkg/*/docs/*.md)
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
MANPAGES ?= $(MANPAGES_MD:%.md=%)
|
2017-11-01 15:24:59 +00:00
|
|
|
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
$(MANPAGES): %: %.md .gopathok
|
2018-05-29 17:18:34 +00:00
|
|
|
@sed -e 's/\((podman.*\.md)\)//' -e 's/\[\(podman.*\)\]/\1/' $< | $(GOMD2MAN) -in /dev/stdin -out $@
|
2018-04-19 03:19:53 +00:00
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
docs: $(MANPAGES) ## Generate documentation
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2019-07-01 18:52:55 +00:00
|
|
|
install-podman-remote-docs: docs
|
|
|
|
|
@(cd docs; ./podman-remote.sh ./remote)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
brew-pkg: install-podman-remote-docs podman-remote-darwin
|
|
|
|
|
@mkdir -p ./brew
|
|
|
|
|
@cp ./bin/podman-remote-darwin ./brew/podman
|
|
|
|
|
@cp -r ./docs/remote ./brew/docs/
|
|
|
|
|
@cp docs/podman-remote.1 ./brew/docs/podman.1
|
|
|
|
|
@sed -i 's/podman\\*-remote/podman/g' ./brew/docs/podman.1
|
|
|
|
|
@sed -i 's/Podman\\*-remote/Podman\ for\ Mac/g' ./brew/docs/podman.1
|
|
|
|
|
@sed -i 's/podman\.conf/podman\-remote\.conf/g' ./brew/docs/podman.1
|
|
|
|
|
@sed -i 's/A\ remote\ CLI\ for\ Podman\:\ //g' ./brew/docs/podman.1
|
|
|
|
|
tar -czvf podman-${RELEASE_NUMBER}.tar.gz ./brew
|
|
|
|
|
@rm -rf ./brew
|
|
|
|
|
|
2018-01-11 15:54:39 +00:00
|
|
|
docker-docs: docs
|
|
|
|
|
(cd docs; ./dckrman.sh *.1)
|
|
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
changelog: ## Generate changelog
|
2018-03-17 14:52:54 +00:00
|
|
|
@echo "Creating changelog from $(CHANGELOG_BASE) to $(CHANGELOG_TARGET)"
|
|
|
|
|
$(eval TMPFILE := $(shell mktemp))
|
|
|
|
|
$(shell cat changelog.txt > $(TMPFILE))
|
|
|
|
|
$(shell echo "- Changelog for $(CHANGELOG_TARGET) ($(ISODATE)):" > changelog.txt)
|
|
|
|
|
$(shell git log --no-merges --format=" * %s" $(CHANGELOG_BASE)..$(CHANGELOG_TARGET) >> changelog.txt)
|
|
|
|
|
$(shell echo "" >> changelog.txt)
|
|
|
|
|
$(shell cat $(TMPFILE) >> changelog.txt)
|
|
|
|
|
$(shell rm $(TMPFILE))
|
|
|
|
|
|
2019-05-17 15:40:45 +00:00
|
|
|
install: .gopathok install.bin install.remote install.man install.cni install.systemd ## Install binaries to system locations
|
|
|
|
|
|
|
|
|
|
install.remote:
|
2019-06-07 05:46:41 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 $(DESTDIR)$(BINDIR)
|
|
|
|
|
install ${SELINUXOPT} -m 755 bin/podman-remote $(DESTDIR)$(BINDIR)/podman-remote
|
|
|
|
|
test -z "${SELINUXOPT}" || chcon --verbose --reference=$(DESTDIR)$(BINDIR)/podman bin/podman-remote
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
|
install.bin:
|
2019-06-07 05:46:41 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 $(DESTDIR)$(BINDIR)
|
|
|
|
|
install ${SELINUXOPT} -m 755 bin/podman $(DESTDIR)$(BINDIR)/podman
|
|
|
|
|
test -z "${SELINUXOPT}" || chcon --verbose --reference=$(DESTDIR)$(BINDIR)/podman bin/podman
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2018-01-11 15:54:39 +00:00
|
|
|
install.man: docs
|
2019-06-07 05:46:41 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 $(DESTDIR)$(MANDIR)/man1
|
|
|
|
|
install ${SELINUXOPT} -d -m 755 $(DESTDIR)$(MANDIR)/man5
|
|
|
|
|
install ${SELINUXOPT} -m 644 $(filter %.1,$(MANPAGES)) -t $(DESTDIR)$(MANDIR)/man1
|
|
|
|
|
install ${SELINUXOPT} -m 644 $(filter %.5,$(MANPAGES)) -t $(DESTDIR)$(MANDIR)/man5
|
|
|
|
|
install ${SELINUXOPT} -m 644 docs/links/*1 -t $(DESTDIR)$(MANDIR)/man1
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
|
install.config:
|
2019-06-07 05:46:41 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 $(DESTDIR)$(SHAREDIR_CONTAINERS)
|
|
|
|
|
install ${SELINUXOPT} -m 644 libpod.conf $(DESTDIR)$(SHAREDIR_CONTAINERS)/libpod.conf
|
|
|
|
|
install ${SELINUXOPT} -m 644 seccomp.json $(DESTDIR)$(SHAREDIR_CONTAINERS)/seccomp.json
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
|
install.completions:
|
2019-06-07 05:46:41 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 ${DESTDIR}${BASHINSTALLDIR}
|
|
|
|
|
install ${SELINUXOPT} -m 644 completions/bash/podman ${DESTDIR}${BASHINSTALLDIR}
|
|
|
|
|
install ${SELINUXOPT} -d -m 755 ${DESTDIR}${ZSHINSTALLDIR}
|
|
|
|
|
install ${SELINUXOPT} -m 644 completions/zsh/_podman ${DESTDIR}${ZSHINSTALLDIR}
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2017-12-20 21:13:52 +00:00
|
|
|
install.cni:
|
2019-06-07 05:46:41 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 ${DESTDIR}${ETCDIR}/cni/net.d/
|
|
|
|
|
install ${SELINUXOPT} -m 644 cni/87-podman-bridge.conflist ${DESTDIR}${ETCDIR}/cni/net.d/87-podman-bridge.conflist
|
2017-12-20 21:13:52 +00:00
|
|
|
|
2018-01-11 15:54:39 +00:00
|
|
|
install.docker: docker-docs
|
2019-06-07 05:46:41 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 $(DESTDIR)$(BINDIR) $(DESTDIR)$(MANDIR)/man1
|
|
|
|
|
install ${SELINUXOPT} -m 755 docker $(DESTDIR)$(BINDIR)/docker
|
|
|
|
|
install ${SELINUXOPT} -m 644 docs/docker*.1 -t $(DESTDIR)$(MANDIR)/man1
|
2018-01-11 15:54:39 +00:00
|
|
|
|
2018-03-26 14:39:14 +00:00
|
|
|
install.systemd:
|
2019-06-07 05:46:41 +00:00
|
|
|
install ${SELINUXOPT} -m 755 -d ${DESTDIR}${SYSTEMDDIR} ${DESTDIR}${TMPFILESDIR}
|
|
|
|
|
install ${SELINUXOPT} -m 644 contrib/varlink/io.podman.socket ${DESTDIR}${SYSTEMDDIR}/io.podman.socket
|
|
|
|
|
install ${SELINUXOPT} -m 644 contrib/varlink/io.podman.service ${DESTDIR}${SYSTEMDDIR}/io.podman.service
|
|
|
|
|
install ${SELINUXOPT} -m 644 contrib/varlink/podman.conf ${DESTDIR}${TMPFILESDIR}/podman.conf
|
2018-03-26 14:39:14 +00:00
|
|
|
|
2017-11-01 15:24:59 +00:00
|
|
|
uninstall:
|
|
|
|
|
for i in $(filter %.1,$(MANPAGES)); do \
|
2019-06-07 05:46:41 +00:00
|
|
|
rm -f $(DESTDIR)$(MANDIR)/man1/$$(basename $${i}); \
|
2018-04-19 03:19:53 +00:00
|
|
|
done; \
|
|
|
|
|
for i in $(filter %.5,$(MANPAGES)); do \
|
2019-06-07 05:46:41 +00:00
|
|
|
rm -f $(DESTDIR)$(MANDIR)/man5/$$(basename $${i}); \
|
2017-11-01 15:24:59 +00:00
|
|
|
done
|
|
|
|
|
|
|
|
|
|
.PHONY: .gitvalidation
|
|
|
|
|
.gitvalidation: .gopathok
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
GIT_CHECK_EXCLUDE="./vendor" $(GOBIN)/git-validation -v -run DCO,short-subject,dangling-whitespace -range $(EPOCH_TEST_COMMIT)..$(HEAD)
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
|
.PHONY: install.tools
|
2019-07-22 18:08:06 +00:00
|
|
|
install.tools: .install.gitvalidation .install.gometalinter .install.md2man .install.ginkgo .install.golangci-lint ## Install needed tools
|
2018-09-13 19:12:04 +00:00
|
|
|
|
2019-06-24 09:15:31 +00:00
|
|
|
define go-get
|
|
|
|
|
env GO111MODULE=off \
|
|
|
|
|
$(GO) get -u ${1}
|
|
|
|
|
endef
|
|
|
|
|
|
2018-09-13 19:12:04 +00:00
|
|
|
.install.ginkgo: .gopathok
|
|
|
|
|
if [ ! -x "$(GOBIN)/ginkgo" ]; then \
|
2019-02-05 10:51:41 +00:00
|
|
|
$(GO) build -o ${GOPATH}/bin/ginkgo ./vendor/github.com/onsi/ginkgo/ginkgo ; \
|
2018-09-13 19:12:04 +00:00
|
|
|
fi
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
|
.install.gitvalidation: .gopathok
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
if [ ! -x "$(GOBIN)/git-validation" ]; then \
|
2019-06-24 09:15:31 +00:00
|
|
|
$(call go-get,github.com/vbatts/git-validation); \
|
2017-11-01 15:24:59 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
.install.gometalinter: .gopathok
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
if [ ! -x "$(GOBIN)/gometalinter" ]; then \
|
2019-06-24 09:15:31 +00:00
|
|
|
$(call go-get,github.com/alecthomas/gometalinter); \
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
cd $(FIRST_GOPATH)/src/github.com/alecthomas/gometalinter; \
|
2018-11-04 14:09:19 +00:00
|
|
|
git checkout e8d801238da6f0dfd14078d68f9b53fa50a7eeb5; \
|
2018-05-21 15:06:28 +00:00
|
|
|
$(GO) install github.com/alecthomas/gometalinter; \
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
$(GOBIN)/gometalinter --install; \
|
2017-11-01 15:24:59 +00:00
|
|
|
fi
|
|
|
|
|
|
2019-07-22 18:08:06 +00:00
|
|
|
.install.golangci-lint: .gopathok
|
|
|
|
|
if [ ! -x "$(GOBIN)/golangci-lint" ]; then \
|
|
|
|
|
curl -sfL https://install.goreleaser.com/github.com/golangci/golangci-lint.sh | sh -s -- -b $(GOBIN)/ v1.17.1; \
|
|
|
|
|
fi
|
|
|
|
|
|
2017-11-01 15:24:59 +00:00
|
|
|
.install.md2man: .gopathok
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
if [ ! -x "$(GOBIN)/go-md2man" ]; then \
|
2019-06-24 09:15:31 +00:00
|
|
|
$(call go-get,github.com/cpuguy83/go-md2man); \
|
2017-11-01 15:24:59 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
.install.ostree: .gopathok
|
|
|
|
|
if ! pkg-config ostree-1 2> /dev/null ; then \
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
git clone https://github.com/ostreedev/ostree $(FIRST_GOPATH)/src/github.com/ostreedev/ostree ; \
|
|
|
|
|
cd $(FIRST_GOPATH)src/github.com/ostreedev/ostree ; \
|
2017-11-01 15:24:59 +00:00
|
|
|
./autogen.sh --prefix=/usr/local; \
|
|
|
|
|
make all install; \
|
|
|
|
|
fi
|
|
|
|
|
|
2019-02-07 08:32:51 +00:00
|
|
|
varlink_generate: .gopathok cmd/podman/varlink/iopodman.go ## Generate varlink
|
2018-05-07 22:09:11 +00:00
|
|
|
varlink_api_generate: .gopathok API.md
|
2018-03-26 14:39:14 +00:00
|
|
|
|
2018-04-28 16:45:51 +00:00
|
|
|
.PHONY: install.libseccomp.sudo
|
|
|
|
|
install.libseccomp.sudo:
|
2018-04-25 18:26:52 +00:00
|
|
|
rm -rf ../../seccomp/libseccomp
|
|
|
|
|
git clone https://github.com/seccomp/libseccomp ../../seccomp/libseccomp
|
|
|
|
|
cd ../../seccomp/libseccomp && git checkout $(LIBSECCOMP_COMMIT) && ./autogen.sh && ./configure --prefix=/usr && make all && make install
|
|
|
|
|
|
|
|
|
|
|
2018-08-02 13:58:59 +00:00
|
|
|
cmd/podman/varlink/iopodman.go: cmd/podman/varlink/io.podman.varlink
|
2019-07-03 20:37:17 +00:00
|
|
|
GO111MODULE=off $(GO) generate ./cmd/podman/varlink/...
|
2018-03-26 14:39:14 +00:00
|
|
|
|
2018-08-02 13:58:59 +00:00
|
|
|
API.md: cmd/podman/varlink/io.podman.varlink
|
2018-05-07 22:09:11 +00:00
|
|
|
$(GO) generate ./docs/...
|
|
|
|
|
|
2019-01-07 14:56:00 +00:00
|
|
|
validate.completions: completions/bash/podman
|
|
|
|
|
. completions/bash/podman
|
2019-03-01 22:39:51 +00:00
|
|
|
if [ -x /bin/zsh ]; then /bin/zsh completions/zsh/_podman; fi
|
2019-01-07 14:56:00 +00:00
|
|
|
|
|
|
|
|
validate: gofmt .gitvalidation validate.completions
|
2018-04-03 17:06:12 +00:00
|
|
|
|
2018-12-12 12:57:18 +00:00
|
|
|
build-all-new-commits:
|
|
|
|
|
# Validate that all the commits build on top of $(GIT_BASE_BRANCH)
|
|
|
|
|
git rebase $(GIT_BASE_BRANCH) -x make
|
|
|
|
|
|
2019-06-29 20:30:57 +00:00
|
|
|
build-no-cgo:
|
|
|
|
|
env BUILDTAGS="containers_image_openpgp containers_image_ostree_stub exclude_graphdriver_btrfs exclude_graphdriver_devicemapper exclude_disk_quota" CGO_ENABLED=0 $(MAKE)
|
|
|
|
|
|
2019-06-24 09:29:13 +00:00
|
|
|
vendor:
|
|
|
|
|
export GO111MODULE=on \
|
|
|
|
|
$(GO) mod tidy && \
|
|
|
|
|
$(GO) mod vendor && \
|
|
|
|
|
$(GO) mod verify
|
2019-01-08 17:00:18 +00:00
|
|
|
|
2017-11-01 15:24:59 +00:00
|
|
|
.PHONY: \
|
Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference. From
[1]:
> The bin directory holds compiled commands. Each command is named
> for its source directory, but only the final element, not the entire
> path. That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands. If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin. GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.
So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...
If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]). In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]). That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.
Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target). The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths. I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.
Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation. And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.
While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok. That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).
As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation. That will give us the same results with
less process setup/teardown penalties.
[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #774
Approved by: mheon
2018-05-15 17:50:56 +00:00
|
|
|
.gopathok \
|
2017-11-01 15:24:59 +00:00
|
|
|
binaries \
|
|
|
|
|
clean \
|
2019-01-07 14:56:00 +00:00
|
|
|
validate.completions \
|
2017-11-01 15:24:59 +00:00
|
|
|
default \
|
|
|
|
|
docs \
|
|
|
|
|
gofmt \
|
|
|
|
|
help \
|
|
|
|
|
install \
|
2019-07-22 18:08:06 +00:00
|
|
|
golangci-lint \
|
2017-11-01 15:24:59 +00:00
|
|
|
lint \
|
|
|
|
|
pause \
|
2018-03-13 15:36:40 +00:00
|
|
|
uninstall \
|
2018-03-17 14:52:54 +00:00
|
|
|
shell \
|
2018-04-03 17:06:12 +00:00
|
|
|
changelog \
|
2018-04-25 18:26:52 +00:00
|
|
|
validate \
|
2018-05-15 01:01:08 +00:00
|
|
|
install.libseccomp.sudo \
|
2019-01-08 17:00:18 +00:00
|
|
|
vendor
|