2017-11-01 15:24:59 +00:00
|
|
|
GO ?= go
|
2018-08-06 12:45:12 +00:00
|
|
|
DESTDIR ?= /
|
2019-01-11 20:31:09 +00:00
|
|
|
EPOCH_TEST_COMMIT ?= 4406e1cfeed18fe89c0ad4e20a3c3b2f4b9ffcae
|
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
|
2017-11-01 15:24:59 +00:00
|
|
|
PREFIX ?= ${DESTDIR}/usr/local
|
|
|
|
BINDIR ?= ${PREFIX}/bin
|
|
|
|
LIBEXECDIR ?= ${PREFIX}/libexec
|
|
|
|
MANDIR ?= ${PREFIX}/share/man
|
2018-03-01 20:33:04 +00:00
|
|
|
SHAREDIR_CONTAINERS ?= ${PREFIX}/share/containers
|
2018-01-17 20:41:56 +00:00
|
|
|
ETCDIR ?= ${DESTDIR}/etc
|
2017-11-02 19:31:21 +00:00
|
|
|
ETCDIR_LIBPOD ?= ${ETCDIR}/crio
|
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
|
2018-09-13 19:12:04 +00:00
|
|
|
BUILDTAGS ?= seccomp $(shell hack/btrfs_tag.sh) $(shell hack/btrfs_installed_tag.sh) $(shell hack/ostree_tag.sh) $(shell hack/selinux_tag.sh) $(shell hack/apparmor_tag.sh) varlink exclude_graphdriver_devicemapper
|
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
|
|
|
|
OCIUMOUNTINSTALLDIR=$(PREFIX)/share/oci-umount/oci-umount.d
|
|
|
|
|
|
|
|
SELINUXOPT ?= $(shell test -x /usr/sbin/selinuxenabled && selinuxenabled && echo -Z)
|
2018-10-29 06:56:23 +00:00
|
|
|
PACKAGES ?= $(shell $(GO) list -tags "${BUILDTAGS}" ./... | grep -v github.com/containers/libpod/vendor | grep -v e2e | grep -v system )
|
2017-11-01 15:24:59 +00:00
|
|
|
|
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)
|
|
|
|
GIT_COMMIT ?= $(if $(shell git status --porcelain --untracked-files=no),"${COMMIT_NO}-dirty","${COMMIT_NO}")
|
|
|
|
BUILD_INFO ?= $(shell date +%s)
|
2018-10-30 22:55:48 +00:00
|
|
|
LIBPOD := ${PROJECT}/libpod
|
|
|
|
LDFLAGS_PODMAN ?= $(LDFLAGS) -X $(LIBPOD).gitCommit=$(GIT_COMMIT) -X $(LIBPOD).buildInfo=$(BUILD_INFO)
|
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
|
|
|
ISODATE ?= $(shell date --iso-8601)
|
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
|
2017-11-01 15:24:59 +00:00
|
|
|
|
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.
|
|
|
|
GINKGOTIMEOUT ?= -timeout=50m
|
|
|
|
|
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-02-06 18:57:46 +00:00
|
|
|
ln -sf "$(CURDIR)" "$(GOPKGBASEDIR)"
|
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-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
|
2018-12-11 14:26:01 +00:00
|
|
|
$(GO) build -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-01-02 20:56:19 +00:00
|
|
|
$(GO) build -ldflags '$(LDFLAGS_PODMAN)' -tags "$(BUILDTAGS) remoteclient" -o bin/$@ $(PROJECT)/cmd/podman
|
|
|
|
|
2019-02-06 17:27:00 +00:00
|
|
|
podman-remote-darwin: .gopathok $(PODMAN_VARLINK_DEPENDENCIES) ## Build with podman on remote OSX environment
|
2019-01-10 18:15:33 +00:00
|
|
|
GOOS=darwin $(GO) build -ldflags '$(LDFLAGS_PODMAN)' -tags "remoteclient containers_image_openpgp exclude_graphdriver_devicemapper" -o bin/$@ $(PROJECT)/cmd/podman
|
|
|
|
|
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##*.}" \
|
2018-12-11 14:26:01 +00:00
|
|
|
$(GO) build -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 \
|
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 \
|
|
|
|
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-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
|
2017-11-01 15:24:59 +00:00
|
|
|
$(GO) test -tags "$(BUILDTAGS)" -cover $(PACKAGES)
|
2018-11-07 14:12:15 +00:00
|
|
|
$(MAKE) -C contrib/cirrus/packer test
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2018-01-24 14:45:55 +00:00
|
|
|
ginkgo:
|
2019-02-05 18:22:42 +00:00
|
|
|
ginkgo -v -tags "$(BUILDTAGS)" $(GINKGOTIMEOUT) -cover -flakeAttempts 3 -progress -trace -noColor 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
|
|
|
|
|
|
|
localintegration: varlink_generate test-binaries ginkgo ginkgo-remote
|
2018-05-15 01:01:08 +00:00
|
|
|
|
2019-02-06 18:57:46 +00:00
|
|
|
localsystem: .install.ginkgo
|
2018-10-29 06:56:23 +00:00
|
|
|
ginkgo -v -noColor test/system/
|
|
|
|
|
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
|
|
|
|
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
|
|
|
|
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-02-06 17:27:00 +00:00
|
|
|
install: .gopathok install.bin install.man install.cni install.systemd ## Install binaries to system locations
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
install.bin:
|
2018-09-17 21:32:02 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 $(BINDIR)
|
|
|
|
install ${SELINUXOPT} -m 755 bin/podman $(BINDIR)/podman
|
2019-01-24 19:17:44 +00:00
|
|
|
test -z "${SELINUXOPT}" || chcon --verbose --reference=$(BINDIR)/podman bin/podman
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2018-01-11 15:54:39 +00:00
|
|
|
install.man: docs
|
2017-11-01 15:24:59 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 $(MANDIR)/man1
|
2018-04-19 03:19:53 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 $(MANDIR)/man5
|
2017-11-01 15:24:59 +00:00
|
|
|
install ${SELINUXOPT} -m 644 $(filter %.1,$(MANPAGES)) -t $(MANDIR)/man1
|
2018-04-19 03:19:53 +00:00
|
|
|
install ${SELINUXOPT} -m 644 $(filter %.5,$(MANPAGES)) -t $(MANDIR)/man5
|
2018-06-25 17:37:17 +00:00
|
|
|
install ${SELINUXOPT} -m 644 docs/links/*1 -t $(MANDIR)/man1
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
install.config:
|
2018-09-17 21:32:02 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 $(SHAREDIR_CONTAINERS) $(ETCDIR_LIBPOD) $(OCIUMOUNTINSTALLDIR)
|
|
|
|
install ${SELINUXOPT} -m 644 libpod.conf $(SHAREDIR_CONTAINERS)/libpod.conf
|
|
|
|
install ${SELINUXOPT} -m 644 seccomp.json $(ETCDIR_LIBPOD)/seccomp.json
|
|
|
|
install ${SELINUXOPT} -m 644 crio-umount.conf $(OCIUMOUNTINSTALLDIR)/crio-umount.conf
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
install.completions:
|
|
|
|
install ${SELINUXOPT} -d -m 755 ${BASHINSTALLDIR}
|
2018-09-17 21:32:02 +00:00
|
|
|
install ${SELINUXOPT} -m 644 completions/bash/podman ${BASHINSTALLDIR}
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2017-12-20 21:13:52 +00:00
|
|
|
install.cni:
|
2018-09-17 21:32:02 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 ${ETCDIR}/cni/net.d/
|
|
|
|
install ${SELINUXOPT} -m 644 cni/87-podman-bridge.conflist ${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
|
2018-09-17 21:32:02 +00:00
|
|
|
install ${SELINUXOPT} -d -m 755 $(BINDIR) $(MANDIR)/man1
|
|
|
|
install ${SELINUXOPT} -m 755 docker $(BINDIR)/docker
|
2018-01-11 15:54:39 +00:00
|
|
|
install ${SELINUXOPT} -m 644 docs/docker*.1 -t $(MANDIR)/man1
|
|
|
|
|
2018-03-26 14:39:14 +00:00
|
|
|
install.systemd:
|
2018-09-17 21:32:02 +00:00
|
|
|
install ${SELINUXOPT} -m 755 -d ${SYSTEMDDIR} ${TMPFILESDIR}
|
|
|
|
install ${SELINUXOPT} -m 644 contrib/varlink/io.podman.socket ${SYSTEMDDIR}/io.podman.socket
|
|
|
|
install ${SELINUXOPT} -m 644 contrib/varlink/io.podman.service ${SYSTEMDDIR}/io.podman.service
|
|
|
|
install ${SELINUXOPT} -m 644 contrib/varlink/podman.conf ${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 \
|
2017-11-01 20:24:45 +00:00
|
|
|
rm -f $(MANDIR)/man1/$$(basename $${i}); \
|
2018-04-19 03:19:53 +00:00
|
|
|
done; \
|
|
|
|
for i in $(filter %.5,$(MANPAGES)); do \
|
|
|
|
rm -f $(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-02-06 17:27:00 +00:00
|
|
|
install.tools: .install.gitvalidation .install.gometalinter .install.md2man .install.ginkgo ## Install needed tools
|
2018-09-13 19:12:04 +00:00
|
|
|
|
2019-02-05 10:51:41 +00:00
|
|
|
.install.vndr: .gopathok
|
2019-02-07 12:20:14 +00:00
|
|
|
$(GO) get -u github.com/LK4D4/vndr
|
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 \
|
2018-05-21 15:06:28 +00:00
|
|
|
$(GO) get -u 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 \
|
2018-05-21 15:06:28 +00:00
|
|
|
$(GO) get -u 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
|
|
|
|
|
|
|
|
.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 \
|
2018-05-21 15:06:28 +00:00
|
|
|
$(GO) get -u 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
|
2018-04-23 18:32:41 +00:00
|
|
|
$(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
|
|
|
|
|
|
|
|
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-02-07 12:20:14 +00:00
|
|
|
vendor: .install.vndr
|
|
|
|
$(GOPATH)/bin/vndr \
|
|
|
|
-whitelist "github.com/varlink/go" \
|
|
|
|
-whitelist "github.com/onsi/ginkgo" \
|
2019-01-31 19:20:04 +00:00
|
|
|
-whitelist "github.com/onsi/gomega" \
|
|
|
|
-whitelist "gopkg.in/fsnotify.v1"
|
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 \
|
|
|
|
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
|