2016-02-18 17:13:00 +03:00
|
|
|
#
|
|
|
|
|
# Installation paths.
|
2017-06-27 21:28:09 +02:00
|
|
|
PREFIX ?= /usr/local
|
Makefile.install: cure LIBDIR guessing logic
Commit 6a51c7e ("make: Allow to install in custom dirs") replaced
all := assignments with ?=, effectively disabling the LIBDIR guessing
logic (as once a variable is assigned, further ?= make no sense).
That commit description says that setting PREFIX from make command line
didn't work. I can't find the original bug report but according to
GNU make documentation (see [1], [2]) as well as to my best knowledge,
any variable set in Makefile can be overridden from the command line,
unless "override VAR = value" is used in the Makefile.
The result of this patch is LIBDIR is correctly set for distros such as
Fedora and Debian, so "make install" works more correct. Surely, any
variable can still be overriden from the command line.
I have also checked the build of Fedora package from criu.spec with this
change -- it works fine.
Now, I am not sure why it was not working for the original bug reporter.
The only hypothesis I have is he tried to do something like
PREFIX=/usr make
instead of
make PREFIX=/usr
If this was the case, it was not a bug but wrong usage.
While at it, fix LIBDIR description in INSTALL.md.
[1] https://www.gnu.org/software/make/manual/html_node/Overriding.html
[2] https://www.gnu.org/software/make/manual/html_node/Override-Directive.html
travis-ci: success for Makefile.install fixes
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
2017-01-06 15:36:05 -08:00
|
|
|
BINDIR := $(PREFIX)/bin
|
|
|
|
|
SBINDIR := $(PREFIX)/sbin
|
|
|
|
|
MANDIR := $(PREFIX)/share/man
|
|
|
|
|
LIBDIR := $(PREFIX)/lib
|
|
|
|
|
INCLUDEDIR := $(PREFIX)/include
|
|
|
|
|
LIBEXECDIR := $(PREFIX)/libexec
|
2017-05-04 16:32:32 +03:00
|
|
|
RUNDIR ?= /run
|
2016-02-15 15:26:55 +03:00
|
|
|
|
2016-02-18 17:13:00 +03:00
|
|
|
#
|
|
|
|
|
# For recent Debian/Ubuntu with multiarch support.
|
Makefile.install: cure LIBDIR guessing logic
Commit 6a51c7e ("make: Allow to install in custom dirs") replaced
all := assignments with ?=, effectively disabling the LIBDIR guessing
logic (as once a variable is assigned, further ?= make no sense).
That commit description says that setting PREFIX from make command line
didn't work. I can't find the original bug report but according to
GNU make documentation (see [1], [2]) as well as to my best knowledge,
any variable set in Makefile can be overridden from the command line,
unless "override VAR = value" is used in the Makefile.
The result of this patch is LIBDIR is correctly set for distros such as
Fedora and Debian, so "make install" works more correct. Surely, any
variable can still be overriden from the command line.
I have also checked the build of Fedora package from criu.spec with this
change -- it works fine.
Now, I am not sure why it was not working for the original bug reporter.
The only hypothesis I have is he tried to do something like
PREFIX=/usr make
instead of
make PREFIX=/usr
If this was the case, it was not a bug but wrong usage.
While at it, fix LIBDIR description in INSTALL.md.
[1] https://www.gnu.org/software/make/manual/html_node/Overriding.html
[2] https://www.gnu.org/software/make/manual/html_node/Override-Directive.html
travis-ci: success for Makefile.install fixes
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
2017-01-06 15:36:05 -08:00
|
|
|
DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH 2>/dev/null)
|
2016-02-18 17:13:00 +03:00
|
|
|
ifneq "$(DEB_HOST_MULTIARCH)" ""
|
Makefile.install: cure LIBDIR guessing logic
Commit 6a51c7e ("make: Allow to install in custom dirs") replaced
all := assignments with ?=, effectively disabling the LIBDIR guessing
logic (as once a variable is assigned, further ?= make no sense).
That commit description says that setting PREFIX from make command line
didn't work. I can't find the original bug report but according to
GNU make documentation (see [1], [2]) as well as to my best knowledge,
any variable set in Makefile can be overridden from the command line,
unless "override VAR = value" is used in the Makefile.
The result of this patch is LIBDIR is correctly set for distros such as
Fedora and Debian, so "make install" works more correct. Surely, any
variable can still be overriden from the command line.
I have also checked the build of Fedora package from criu.spec with this
change -- it works fine.
Now, I am not sure why it was not working for the original bug reporter.
The only hypothesis I have is he tried to do something like
PREFIX=/usr make
instead of
make PREFIX=/usr
If this was the case, it was not a bug but wrong usage.
While at it, fix LIBDIR description in INSTALL.md.
[1] https://www.gnu.org/software/make/manual/html_node/Overriding.html
[2] https://www.gnu.org/software/make/manual/html_node/Override-Directive.html
travis-ci: success for Makefile.install fixes
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
2017-01-06 15:36:05 -08:00
|
|
|
LIBDIR := $(PREFIX)/lib/$(DEB_HOST_MULTIARCH)
|
2016-02-18 17:13:00 +03:00
|
|
|
else
|
|
|
|
|
#
|
|
|
|
|
# For most other systems
|
|
|
|
|
ifeq "$(shell uname -m)" "x86_64"
|
Makefile.install: cure LIBDIR guessing logic
Commit 6a51c7e ("make: Allow to install in custom dirs") replaced
all := assignments with ?=, effectively disabling the LIBDIR guessing
logic (as once a variable is assigned, further ?= make no sense).
That commit description says that setting PREFIX from make command line
didn't work. I can't find the original bug report but according to
GNU make documentation (see [1], [2]) as well as to my best knowledge,
any variable set in Makefile can be overridden from the command line,
unless "override VAR = value" is used in the Makefile.
The result of this patch is LIBDIR is correctly set for distros such as
Fedora and Debian, so "make install" works more correct. Surely, any
variable can still be overriden from the command line.
I have also checked the build of Fedora package from criu.spec with this
change -- it works fine.
Now, I am not sure why it was not working for the original bug reporter.
The only hypothesis I have is he tried to do something like
PREFIX=/usr make
instead of
make PREFIX=/usr
If this was the case, it was not a bug but wrong usage.
While at it, fix LIBDIR description in INSTALL.md.
[1] https://www.gnu.org/software/make/manual/html_node/Overriding.html
[2] https://www.gnu.org/software/make/manual/html_node/Override-Directive.html
travis-ci: success for Makefile.install fixes
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
2017-01-06 15:36:05 -08:00
|
|
|
LIBDIR := $(PREFIX)/lib64
|
2016-02-18 17:13:00 +03:00
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
2017-05-04 16:32:32 +03:00
|
|
|
export PREFIX BINDIR SBINDIR MANDIR RUNDIR
|
2017-01-06 15:36:06 -08:00
|
|
|
export LIBDIR INCLUDEDIR LIBEXECDIR
|
2016-02-15 15:26:55 +03:00
|
|
|
|
|
|
|
|
install-man:
|
|
|
|
|
$(Q) $(MAKE) -C Documentation install
|
2016-02-18 17:13:00 +03:00
|
|
|
.PHONY: install-man
|
|
|
|
|
|
|
|
|
|
install-lib: lib
|
2017-02-22 15:15:42 -08:00
|
|
|
$(Q) $(MAKE) $(build)=lib install
|
2016-02-18 17:13:00 +03:00
|
|
|
.PHONY: install-lib
|
2016-02-15 15:26:55 +03:00
|
|
|
|
2016-02-18 17:13:00 +03:00
|
|
|
install-criu: criu
|
build/make: return to make from top directory
It looks like, there is not so much that needs to be fixed for
building criu from a top directory.
After the patch it's possible to do `make criu/mount.o` i.e.
It will build protobuf, compel as dependencies (if they are not built),
but no more from criu objects. If something breaks, you can
do make from vim and jump to error. Nice.
Mostly the patch corrects pathes to objects - I tried to make them
depend on $(obj) or $(SRC_DIR)/criu, where it's possible.
After it tested:
`make -j 10`, `make criu/log.o`, `make clean`, `make mrproper`,
`make install DESTDIR=/tmp/criu`, `make uninstall DESTDIR=/tmp/criu`
Note: I improperly called v1 for this patch as "return to make from
top Makefile" -- but I didn't mean that (and it was friday ;)
This patch doesn't yet switch to top-Makefile building, but that's
a step in that way (building from a top Makefile needs correct pathes
in makefiles) which also adds ability to build objects in subdirectories
and etc.
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
2016-07-18 22:22:48 +03:00
|
|
|
$(Q) $(MAKE) $(build)=criu install
|
2016-02-18 17:13:00 +03:00
|
|
|
.PHONY: install-criu
|
2016-02-15 15:26:55 +03:00
|
|
|
|
2016-11-25 18:11:54 +03:00
|
|
|
install-compel: $(compel-install-targets)
|
|
|
|
|
$(Q) $(MAKE) $(build)=compel install
|
|
|
|
|
$(Q) $(MAKE) $(build)=compel/plugins install
|
|
|
|
|
.PHONY: install-compel
|
|
|
|
|
|
2017-02-22 15:15:48 -08:00
|
|
|
install: install-man install-lib install-criu install-compel ;
|
2016-02-18 17:13:00 +03:00
|
|
|
.PHONY: install
|
2016-04-20 12:11:52 +03:00
|
|
|
|
|
|
|
|
uninstall:
|
|
|
|
|
$(Q) $(MAKE) -C Documentation $@
|
2017-02-22 15:15:42 -08:00
|
|
|
$(Q) $(MAKE) $(build)=lib $@
|
2017-02-22 15:15:43 -08:00
|
|
|
$(Q) $(MAKE) $(build)=criu $@
|
2016-11-25 18:11:54 +03:00
|
|
|
$(Q) $(MAKE) $(build)=compel $@
|
|
|
|
|
$(Q) $(MAKE) $(build)=compel/plugins $@
|
2016-04-20 12:11:52 +03:00
|
|
|
.PHONY: uninstall
|