2017-11-01 15:24:59 +00:00
|
|
|
GO ?= go
|
2018-08-06 12:45:12 +00:00
|
|
|
DESTDIR ?= /
|
2018-11-08 19:09:03 +00:00
|
|
|
EPOCH_TEST_COMMIT ?= 921ccac10c47e0865ec5e4ba00ebb69a03d89473
|
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
|
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)
|
2018-06-22 13:56:08 +00:00
|
|
|
|
2018-05-30 21:22:15 +00:00
|
|
|
HAS_PYTHON3 := $(shell command -v python3 2>/dev/null)
|
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-08-16 10:41:15 +00:00
|
|
|
PACKAGES ?= $(shell $(GO) list -tags "${BUILDTAGS}" ./... | grep -v github.com/containers/libpod/vendor | grep -v e2e)
|
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)
|
2018-04-25 18:26:52 +00:00
|
|
|
LIBSECCOMP_COMMIT := release-2.3
|
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
|
|
|
|
|
|
|
|
|
|
help:
|
|
|
|
|
@echo "Usage: make <target>"
|
|
|
|
|
@echo
|
|
|
|
|
@echo " * 'install' - Install binaries to system locations"
|
2018-04-02 19:10:26 +00:00
|
|
|
@echo " * 'binaries' - Build podman"
|
2017-11-01 15:24:59 +00:00
|
|
|
@echo " * 'integration' - Execute integration tests"
|
|
|
|
|
@echo " * 'clean' - Clean artifacts"
|
|
|
|
|
@echo " * 'lint' - Execute the source code linter"
|
|
|
|
|
@echo " * 'gofmt' - Verify the source code gofmt"
|
|
|
|
|
|
|
|
|
|
.gopathok:
|
|
|
|
|
ifeq ("$(wildcard $(GOPKGDIR))","")
|
|
|
|
|
mkdir -p "$(GOPKGBASEDIR)"
|
|
|
|
|
ln -s "$(CURDIR)" "$(GOPKGBASEDIR)"
|
|
|
|
|
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
|
|
|
|
2018-03-26 14:39:14 +00:00
|
|
|
lint: .gopathok varlink_generate
|
2017-11-01 15:24:59 +00:00
|
|
|
@echo "checking lint"
|
|
|
|
|
@./.tool/lint
|
2018-07-17 00:29:50 +00:00
|
|
|
# Not ready
|
|
|
|
|
# @$(MAKE) -C contrib/python/podman lint
|
|
|
|
|
# @$(MAKE) -C contrib/python/pypodman lint
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
|
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/bin2img/bin2img: .gopathok $(wildcard test/bin2img/*.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/bin2img
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
|
test/copyimg/copyimg: .gopathok $(wildcard test/copyimg/*.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/copyimg
|
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-06-22 13:56:08 +00:00
|
|
|
podman: .gopathok $(PODMAN_VARLINK_DEPENDENCIES)
|
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 -i -ldflags '$(LDFLAGS_PODMAN)' -tags "$(BUILDTAGS)" -o bin/$@ $(PROJECT)/cmd/podman
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2018-06-29 21:47:53 +00:00
|
|
|
local-cross: $(CROSS_BUILD_TARGETS)
|
|
|
|
|
|
|
|
|
|
bin/podman.cross.%: .gopathok
|
|
|
|
|
TARGET="$*"; \
|
|
|
|
|
GOOS="$${TARGET%%.*}" \
|
|
|
|
|
GOARCH="$${TARGET##*.}" \
|
|
|
|
|
$(GO) build -i -ldflags '$(LDFLAGS_PODMAN)' -tags '$(BUILDTAGS_CROSS)' -o "$@" $(PROJECT)/cmd/podman
|
2018-06-20 18:23:24 +00:00
|
|
|
|
2018-07-17 00:29:50 +00:00
|
|
|
python:
|
2018-05-20 15:50:06 +00:00
|
|
|
ifdef HAS_PYTHON3
|
2018-07-13 02:26:14 +00:00
|
|
|
$(MAKE) -C contrib/python/podman python-podman
|
|
|
|
|
$(MAKE) -C contrib/python/pypodman python-pypodman
|
2018-05-20 15:50:06 +00:00
|
|
|
endif
|
2018-05-15 01:01:08 +00:00
|
|
|
|
2017-11-01 15:24:59 +00:00
|
|
|
clean:
|
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/bin2img/bin2img \
|
|
|
|
|
test/checkseccomp/checkseccomp \
|
|
|
|
|
test/copyimg/copyimg \
|
|
|
|
|
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
|
2018-05-21 17:24:26 +00:00
|
|
|
$(MAKE) -C contrib/python/podman clean
|
|
|
|
|
$(MAKE) -C contrib/python/pypodman clean
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2017-11-02 19:31:21 +00:00
|
|
|
libpodimage:
|
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
|
|
|
|
2018-03-07 15:14:17 +00:00
|
|
|
test: libpodimage
|
2018-10-23 21:36:35 +00:00
|
|
|
${CONTAINER_RUNTIME} run -e STORAGE_OPTIONS="--storage-driver=vfs" -e TESTFLAGS -e CGROUP_MANAGER=cgroupfs -e TRAVIS -t --privileged --rm -v ${CURDIR}:/go/src/${PROJECT} ${LIBPOD_IMAGE} make clean all localunit localintegration
|
2018-03-07 15:14:17 +00:00
|
|
|
|
2017-11-02 19:31:21 +00:00
|
|
|
integration: libpodimage
|
2018-10-23 21:36:35 +00:00
|
|
|
${CONTAINER_RUNTIME} run -e STORAGE_OPTIONS="--storage-driver=vfs" -e TESTFLAGS -e CGROUP_MANAGER=cgroupfs -e TRAVIS -t --privileged --rm -v ${CURDIR}:/go/src/${PROJECT} ${LIBPOD_IMAGE} make clean all 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
|
|
|
|
|
|
2018-03-13 15:36:40 +00:00
|
|
|
shell: libpodimage
|
2018-10-23 21:36:35 +00:00
|
|
|
${CONTAINER_RUNTIME} run --tmpfs -e STORAGE_OPTIONS="--storage-driver=vfs" -e CGROUP_MANAGER=cgroupfs -e TESTFLAGS -e TRAVIS -it --privileged --rm -v ${CURDIR}:/go/src/${PROJECT} ${LIBPOD_IMAGE} sh
|
2018-03-13 15:36:40 +00:00
|
|
|
|
2018-03-07 15:14:17 +00:00
|
|
|
testunit: libpodimage
|
2018-10-23 21:36:35 +00:00
|
|
|
${CONTAINER_RUNTIME} run -e STORAGE_OPTIONS="--storage-driver=vfs" -e TESTFLAGS -e CGROUP_MANAGER=cgroupfs -e TRAVIS -t --privileged --rm -v ${CURDIR}:/go/src/${PROJECT} ${LIBPOD_IMAGE} make localunit
|
2018-03-07 15:14:17 +00:00
|
|
|
|
2018-03-26 14:39:14 +00:00
|
|
|
localunit: varlink_generate
|
2017-11-01 15:24:59 +00:00
|
|
|
$(GO) test -tags "$(BUILDTAGS)" -cover $(PACKAGES)
|
|
|
|
|
|
2018-01-24 14:45:55 +00:00
|
|
|
ginkgo:
|
2018-09-13 19:12:04 +00:00
|
|
|
ginkgo -v -tags "$(BUILDTAGS)" -cover -flakeAttempts 3 -progress -trace -noColor test/e2e/.
|
2018-01-24 14:45:55 +00:00
|
|
|
|
2018-09-13 19:12:04 +00:00
|
|
|
localintegration: varlink_generate test-binaries clientintegration ginkgo
|
2018-05-15 01:01:08 +00:00
|
|
|
|
|
|
|
|
clientintegration:
|
2018-07-13 02:26:14 +00:00
|
|
|
$(MAKE) -C contrib/python/podman integration
|
|
|
|
|
$(MAKE) -C contrib/python/pypodman integration
|
2017-11-01 15:24:59 +00:00
|
|
|
|
2017-11-03 19:37:22 +00:00
|
|
|
vagrant-check:
|
|
|
|
|
BOX=$(BOX) sh ./vagrant.sh
|
|
|
|
|
|
2018-09-11 20:22:36 +00:00
|
|
|
binaries: varlink_generate easyjson_generate podman
|
2017-11-02 19:31:21 +00:00
|
|
|
|
2017-11-01 15:24:59 +00:00
|
|
|
test-binaries: test/bin2img/bin2img test/copyimg/copyimg test/checkseccomp/checkseccomp
|
|
|
|
|
|
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
|
|
|
|
2017-11-01 15:24:59 +00:00
|
|
|
docs: $(MANPAGES)
|
|
|
|
|
|
2018-01-11 15:54:39 +00:00
|
|
|
docker-docs: docs
|
|
|
|
|
(cd docs; ./dckrman.sh *.1)
|
|
|
|
|
|
2018-03-17 14:52:54 +00:00
|
|
|
changelog:
|
|
|
|
|
@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))
|
|
|
|
|
|
2018-07-17 00:29:50 +00:00
|
|
|
install: .gopathok install.bin install.man install.cni install.systemd install.python
|
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
|
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
|
|
|
|
2018-07-17 00:29:50 +00:00
|
|
|
install.python:
|
2018-08-06 12:45:12 +00:00
|
|
|
$(MAKE) DESTDIR=${DESTDIR} -C contrib/python/podman install
|
|
|
|
|
$(MAKE) DESTDIR=${DESTDIR} -C contrib/python/pypodman install
|
2018-07-17 00:29:50 +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
|
2018-07-17 00:29:50 +00:00
|
|
|
$(MAKE) -C contrib/python/pypodman uninstall
|
|
|
|
|
$(MAKE) -C contrib/python/podman uninstall
|
2017-11-01 15:24:59 +00:00
|
|
|
|
|
|
|
|
.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
|
|
|
|
|
|
2018-09-13 19:12:04 +00:00
|
|
|
install.tools: .install.gitvalidation .install.gometalinter .install.md2man .install.easyjson .install.ginkgo .install.gomega
|
|
|
|
|
|
|
|
|
|
.install.gomega: .gopathok
|
|
|
|
|
$(GO) get github.com/onsi/gomega/...
|
|
|
|
|
|
|
|
|
|
.install.ginkgo: .gopathok
|
|
|
|
|
if [ ! -x "$(GOBIN)/ginkgo" ]; then \
|
|
|
|
|
$(GO) get -u github.com/onsi/ginkgo/ginkgo; \
|
|
|
|
|
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; \
|
2017-11-01 15:24:59 +00:00
|
|
|
git checkout 23261fa046586808612c61da7a81d75a658e0814; \
|
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
|
|
|
|
|
|
2018-08-22 13:12:40 +00:00
|
|
|
.install.easyjson: .gopathok
|
2018-09-13 19:12:04 +00:00
|
|
|
if [ ! -x "$(GOBIN)/easyffjson" ]; then \
|
2018-08-22 13:12:40 +00:00
|
|
|
$(GO) get -u github.com/mailru/easyjson/...; \
|
2018-08-09 14:36:51 +00:00
|
|
|
fi
|
|
|
|
|
|
2017-11-01 15:24:59 +00:00
|
|
|
.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
|
|
|
|
|
|
2018-08-02 13:58:59 +00:00
|
|
|
varlink_generate: .gopathok cmd/podman/varlink/iopodman.go
|
2018-05-07 22:09:11 +00:00
|
|
|
varlink_api_generate: .gopathok API.md
|
2018-03-26 14:39:14 +00:00
|
|
|
|
2018-08-22 13:12:40 +00:00
|
|
|
easyjson_generate: .gopathok libpod/container_easyjson.go libpod/pod_easyjson.go
|
2018-08-09 14:36:51 +00:00
|
|
|
|
2018-08-22 13:12:40 +00:00
|
|
|
libpod/container_easyjson.go: libpod/container.go
|
|
|
|
|
rm -f libpod/container_easyjson.go
|
2018-09-13 19:12:04 +00:00
|
|
|
cd "$(GOPKGDIR)" && easyjson -build_tags "$(BUILDTAGS)" ./libpod/container.go
|
2018-08-09 14:36:51 +00:00
|
|
|
|
2018-08-22 13:12:40 +00:00
|
|
|
libpod/pod_easyjson.go: libpod/pod.go
|
|
|
|
|
rm -f libpod/pod_easyjson.go
|
2018-09-13 19:12:04 +00:00
|
|
|
cd "$(GOPKGDIR)" && easyjson -build_tags "$(BUILDTAGS)" ./libpod/pod.go
|
2018-08-09 14:36:51 +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/...
|
|
|
|
|
|
2018-04-03 17:06:12 +00:00
|
|
|
validate: gofmt .gitvalidation
|
|
|
|
|
|
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 \
|
|
|
|
|
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 \
|
2018-07-17 00:29:50 +00:00
|
|
|
python \
|
2018-05-15 01:01:08 +00:00
|
|
|
clientintegration
|