kumquat-buildroot/package/pkg-python.mk

304 lines
10 KiB
Makefile
Raw Normal View History

################################################################################
# Python package infrastructure
#
# This file implements an infrastructure that eases development of
# package .mk files for Python packages. It should be used for all
# packages that use Python setup.py/setuptools as their build system.
#
# See the Buildroot documentation for details on the usage of this
# infrastructure
#
# In terms of implementation, this Python infrastructure requires the
# .mk file to only specify metadata information about the package:
# name, version, download URL, etc.
#
# We still allow the package .mk file to override what the different
# steps are doing, if needed. For example, if <PKG>_BUILD_CMDS is
# already defined, it is used as the list of commands to perform to
# build the package, instead of the default Python behaviour. The
# package can also define some post operation hooks.
#
################################################################################
define PKG_PYTHON_SYSCONFIGDATA_NAME
$(basename $(notdir $(wildcard $(STAGING_DIR)/usr/lib/python$(PYTHON3_VERSION_MAJOR)/_sysconfigdata__linux_*.py)))
endef
# Target distutils-based packages
PKG_PYTHON_DISTUTILS_ENV = \
PATH=$(BR_PATH) \
$(TARGET_CONFIGURE_OPTS) \
LDSHARED="$(TARGET_CROSS)gcc -shared" \
PYTHONPATH="$(if $(BR2_PACKAGE_PYTHON3),$(PYTHON3_PATH),$(PYTHON_PATH))" \
PYTHONNOUSERSITE=1 \
_PYTHON_SYSCONFIGDATA_NAME="$(PKG_PYTHON_SYSCONFIGDATA_NAME)" \
_python_sysroot=$(STAGING_DIR) \
_python_prefix=/usr \
_python_exec_prefix=/usr
PKG_PYTHON_DISTUTILS_BUILD_OPTS = \
--executable=/usr/bin/python
PKG_PYTHON_DISTUTILS_INSTALL_TARGET_OPTS = \
--prefix=/usr \
--root=$(TARGET_DIR)
PKG_PYTHON_DISTUTILS_INSTALL_STAGING_OPTS = \
--prefix=/usr \
--root=$(STAGING_DIR)
# Host distutils-based packages
HOST_PKG_PYTHON_DISTUTILS_ENV = \
PATH=$(BR_PATH) \
PYTHONNOUSERSITE=1 \
$(HOST_CONFIGURE_OPTS)
HOST_PKG_PYTHON_DISTUTILS_INSTALL_OPTS = \
--prefix=$(HOST_DIR)
# Target setuptools-based packages
PKG_PYTHON_SETUPTOOLS_ENV = \
_PYTHON_SYSCONFIGDATA_NAME="$(PKG_PYTHON_SYSCONFIGDATA_NAME)" \
PATH=$(BR_PATH) \
$(TARGET_CONFIGURE_OPTS) \
PYTHONPATH="$(if $(BR2_PACKAGE_PYTHON3),$(PYTHON3_PATH),$(PYTHON_PATH))" \
PYTHONNOUSERSITE=1 \
_python_sysroot=$(STAGING_DIR) \
_python_prefix=/usr \
_python_exec_prefix=/usr
PKG_PYTHON_SETUPTOOLS_INSTALL_TARGET_OPTS = \
--prefix=/usr \
--executable=/usr/bin/python \
--single-version-externally-managed \
--root=$(TARGET_DIR)
PKG_PYTHON_SETUPTOOLS_INSTALL_STAGING_OPTS = \
--prefix=/usr \
--executable=/usr/bin/python \
--single-version-externally-managed \
--root=$(STAGING_DIR)
# Host setuptools-based packages
HOST_PKG_PYTHON_SETUPTOOLS_ENV = \
PATH=$(BR_PATH) \
PYTHONNOUSERSITE=1 \
$(HOST_CONFIGURE_OPTS)
HOST_PKG_PYTHON_SETUPTOOLS_INSTALL_OPTS = \
package/pkg-python: use --single-version-externally-managed for host setuptools Currently, host Python packages that use setuptools are installed as Python Eggs, i.e they are installed in $(HOST_DIR)/lib/python2.7/site-packages/Something-<version>.egg. Once installed, each Python Egg is registered to a file called $(HOST_DIR)/lib/python2.7/site-packages/easy-install.pth. This file is read by the Python interpreter so that the installation location of each Egg is added to the Python path, and can be found by the Python interpreter. However, the fact that the installation of different Python modules need to update a common file is clearly not compatible with per-package directories and top-level parallel build. To fix this, we avoid using Python Eggs using the same --single-version-externally-managed option that we use for target modules. This option is normally meant for distributions packaging Python modules, and can therefore only be used if either --record (to record the list of files being installed) or --root is passed. --root=/ works fine and was suggested by https://stackoverflow.com/questions/6301003/stopping-setup-py-from-installing-as-egg/33791008#33791008. With this change, host Python modules installed by setuptools are now installed in the "regular" way, i.e directly in $(HOST_DIR)/lib/python2.7/site-packages/mako for host-python-mako. This makes the installation of host Python modules more similar to the one of target modules, and makes it compatible with per-package directory support and top-level parallel build. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Asaf Kahlon <asafka7@gmail.com> Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-12-28 18:01:31 +01:00
--prefix=$(HOST_DIR) \
--root=/ \
--single-version-externally-managed
################################################################################
# inner-python-package -- defines how the configuration, compilation
# and installation of a Python package should be done, implements a
# few hooks to tune the build process and calls the generic package
# infrastructure to generate the necessary make targets
#
# argument 1 is the lowercase package name
# argument 2 is the uppercase package name, including a HOST_ prefix
# for host packages
# argument 3 is the uppercase package name, without the HOST_ prefix
# for host packages
# argument 4 is the type (target or host)
################################################################################
define inner-python-package
$(2)_ENV ?=
$(2)_BUILD_OPTS ?=
$(2)_INSTALL_OPTS ?=
ifndef $(2)_SETUP_TYPE
ifdef $(3)_SETUP_TYPE
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 21:12:24 +02:00
$(2)_SETUP_TYPE = $$($(3)_SETUP_TYPE)
else
$$(error "$(2)_SETUP_TYPE must be set")
endif
endif
# Distutils
ifeq ($$($(2)_SETUP_TYPE),distutils)
ifeq ($(4),target)
$(2)_BASE_ENV = $$(PKG_PYTHON_DISTUTILS_ENV)
$(2)_BASE_BUILD_TGT = build
$(2)_BASE_BUILD_OPTS = $$(PKG_PYTHON_DISTUTILS_BUILD_OPTS)
$(2)_BASE_INSTALL_TARGET_OPTS = $$(PKG_PYTHON_DISTUTILS_INSTALL_TARGET_OPTS)
$(2)_BASE_INSTALL_STAGING_OPTS = $$(PKG_PYTHON_DISTUTILS_INSTALL_STAGING_OPTS)
else
$(2)_BASE_ENV = $$(HOST_PKG_PYTHON_DISTUTILS_ENV)
$(2)_BASE_BUILD_TGT = build
$(2)_BASE_BUILD_OPTS =
$(2)_BASE_INSTALL_OPTS = $$(HOST_PKG_PYTHON_DISTUTILS_INSTALL_OPTS)
endif
# Setuptools
else ifeq ($$($(2)_SETUP_TYPE),setuptools)
ifeq ($(4),target)
$(2)_BASE_ENV = $$(PKG_PYTHON_SETUPTOOLS_ENV)
$(2)_BASE_BUILD_TGT = build
$(2)_BASE_BUILD_OPTS =
$(2)_BASE_INSTALL_TARGET_OPTS = $$(PKG_PYTHON_SETUPTOOLS_INSTALL_TARGET_OPTS)
$(2)_BASE_INSTALL_STAGING_OPTS = $$(PKG_PYTHON_SETUPTOOLS_INSTALL_STAGING_OPTS)
else
$(2)_BASE_ENV = $$(HOST_PKG_PYTHON_SETUPTOOLS_ENV)
$(2)_BASE_BUILD_TGT = build
$(2)_BASE_BUILD_OPTS =
$(2)_BASE_INSTALL_OPTS = $$(HOST_PKG_PYTHON_SETUPTOOLS_INSTALL_OPTS)
endif
else
$$(error "Invalid $(2)_SETUP_TYPE. Valid options are 'distutils' or 'setuptools'")
endif
# Target packages need both the python interpreter on the target (for
# runtime) and the python interpreter on the host (for
# compilation). However, host packages only need the python
pkg-python: support host-python dependency different from the python in the target Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 23:04:42 +01:00
# interpreter on the host, whose version may be enforced by setting
# the *_NEEDS_HOST_PYTHON variable.
#
# So:
# - for target packages, we always depend on the default python interpreter
# (the one selected by the config);
# - for host packages:
# - if *_NEEDS_HOST_PYTHON is not set, then we depend on use the default
# interperter;
# - otherwise, we depend on the one requested by *_NEEDS_HOST_PYTHON.
#
ifeq ($(4),target)
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 21:12:24 +02:00
$(2)_DEPENDENCIES += $$(if $$(BR2_PACKAGE_PYTHON3),host-python3 python3,host-python python)
else
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 21:12:24 +02:00
ifeq ($$($(2)_NEEDS_HOST_PYTHON),)
$(2)_DEPENDENCIES += $$(if $$(BR2_PACKAGE_PYTHON3),host-python3,host-python)
pkg-python: support host-python dependency different from the python in the target Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 23:04:42 +01:00
else
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 21:12:24 +02:00
ifeq ($$($(2)_NEEDS_HOST_PYTHON),python2)
pkg-python: support host-python dependency different from the python in the target Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 23:04:42 +01:00
$(2)_DEPENDENCIES += host-python
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 21:12:24 +02:00
else ifeq ($$($(2)_NEEDS_HOST_PYTHON),python3)
pkg-python: support host-python dependency different from the python in the target Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 23:04:42 +01:00
$(2)_DEPENDENCIES += host-python3
else
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 21:12:24 +02:00
$$(error Incorrect value '$$($(2)_NEEDS_HOST_PYTHON)' for $(2)_NEEDS_HOST_PYTHON)
endif
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 21:12:24 +02:00
endif # ($$($(2)_NEEDS_HOST_PYTHON),)
pkg-python: support host-python dependency different from the python in the target Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 23:04:42 +01:00
endif # ($(4),target)
package/pkg-python: use host-python3-setuptools when needed When a package uses "setuptools" as its <pkg>_SETUP_TYPE, we currently add a dependency on host-python-setuptools. This means that: (1) When BR2_PACKAGE_PYTHON=y, the default host Python version is Python 2.x, and host-python-setuptools is installed for host-python. (2) When BR2_PACKAGE_PYTHON3=y, the default host Python version is Python 3.x, and host-python-setuptools is installed for host-python3. (3) When no target Python interpreter is selected, the default host Python version is Python 2.x, and host-python-setuptools is installed for host-python. Situations (1) and (3) are problematic for host Python packages that need Python 3.x. Such packages use <pkg>_NEEDS_HOST_PYTHON = python3, but if they use setuptools as their setup type, they will not find setuptools installed for host-python3 in situations (1) and (3) described above. We currently have a single package that sets <pkg>_NEEDS_HOST_PYTHON = python3: host-meson. host-meson generally works because if setuptools is not found, it falls back to distutils, which is part of the standard Python library. However, if there is a setuptools version installed system-wide, it may be picked up, but may not necessarily be the same version as Buildroot setuptools, potentially causing problems. This commit makes the necessary change to the python-package infrastructure to fix this behavior, by identifying the following cases: - When a host Python package says <pkg>_NEEDS_HOST_PYTHON = python3, then we know it wants setuptools installed for host-python3, so we use host-python3-setuptools. - When a host Python package says <pkg>_NEEDS_HOST_PYTHON = python2, then we known it wants setuptools installed for host-python, so we use host-python-setuptools. - When BR2_PACKAGE_PYTHON3=y, and we have a target package, or a host package with no NEEDS_HOST_PYTHON option, then we want setuptools installed for host-python3, so we use host-python3-setuptools. - When BR2_PACKAGE_PYTHON=y or no target interpreter is enabled at all, and we have a target package, or a host package with no NEEDS_HOST_PYTHON option, then we want setuptools for host-python, so we use host-python-setuptools. To make this happen, we use host-python3-setuptools introduced in a previous commit, but we also change host-python-setuptools to force its installation for host-python. The latter is needed if you build with BR2_PACKAGE_PYTHON3=y but want to install a Python-based package that has NEEDS_HOST_PYTHON=python2. There is one single package that needs be adjusted following this: lirc-tools, because it is not using the python-package infrastructure. It directly depends on host-python-setuptools, which no longer works because host-python-setuptools now only installs for Python 2.x, while lirc-tools Python binding only supports Python 3.x. Switching to host-python3-setuptools solves this problem. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Asaf Kahlon <asafka7@gmail.com> Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-12-28 18:01:30 +01:00
# Setuptools based packages will need setuptools for the host Python
# interpreter (both host and target).
#
# If we have a host package that says "I need Python 3", we install
# setuptools for python3.
#
# If we have a host packge that says "I need Python 2", we install
# setuptools for python2.
#
# If we have a target package, or a host package that doesn't have any
# <pkg>_NEEDS_HOST_PYTHON, and BR2_PACKAGE_PYTHON3 is used, then
# Python 3.x is the default Python interpreter, so we install
# setuptools for python3.
#
# In all other cases, we install setuptools for python2. Those other
# cases are: a target package or host package with
# BR2_PACKAGE_PYTHON=y, or a host-package with neither
# BR2_PACKAGE_PYTHON3=y or BR2_PACKAGE_PYTHON=y.
ifeq ($$($(2)_SETUP_TYPE),setuptools)
package/pkg-python: use host-python3-setuptools when needed When a package uses "setuptools" as its <pkg>_SETUP_TYPE, we currently add a dependency on host-python-setuptools. This means that: (1) When BR2_PACKAGE_PYTHON=y, the default host Python version is Python 2.x, and host-python-setuptools is installed for host-python. (2) When BR2_PACKAGE_PYTHON3=y, the default host Python version is Python 3.x, and host-python-setuptools is installed for host-python3. (3) When no target Python interpreter is selected, the default host Python version is Python 2.x, and host-python-setuptools is installed for host-python. Situations (1) and (3) are problematic for host Python packages that need Python 3.x. Such packages use <pkg>_NEEDS_HOST_PYTHON = python3, but if they use setuptools as their setup type, they will not find setuptools installed for host-python3 in situations (1) and (3) described above. We currently have a single package that sets <pkg>_NEEDS_HOST_PYTHON = python3: host-meson. host-meson generally works because if setuptools is not found, it falls back to distutils, which is part of the standard Python library. However, if there is a setuptools version installed system-wide, it may be picked up, but may not necessarily be the same version as Buildroot setuptools, potentially causing problems. This commit makes the necessary change to the python-package infrastructure to fix this behavior, by identifying the following cases: - When a host Python package says <pkg>_NEEDS_HOST_PYTHON = python3, then we know it wants setuptools installed for host-python3, so we use host-python3-setuptools. - When a host Python package says <pkg>_NEEDS_HOST_PYTHON = python2, then we known it wants setuptools installed for host-python, so we use host-python-setuptools. - When BR2_PACKAGE_PYTHON3=y, and we have a target package, or a host package with no NEEDS_HOST_PYTHON option, then we want setuptools installed for host-python3, so we use host-python3-setuptools. - When BR2_PACKAGE_PYTHON=y or no target interpreter is enabled at all, and we have a target package, or a host package with no NEEDS_HOST_PYTHON option, then we want setuptools for host-python, so we use host-python-setuptools. To make this happen, we use host-python3-setuptools introduced in a previous commit, but we also change host-python-setuptools to force its installation for host-python. The latter is needed if you build with BR2_PACKAGE_PYTHON3=y but want to install a Python-based package that has NEEDS_HOST_PYTHON=python2. There is one single package that needs be adjusted following this: lirc-tools, because it is not using the python-package infrastructure. It directly depends on host-python-setuptools, which no longer works because host-python-setuptools now only installs for Python 2.x, while lirc-tools Python binding only supports Python 3.x. Switching to host-python3-setuptools solves this problem. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Asaf Kahlon <asafka7@gmail.com> Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-12-28 18:01:30 +01:00
ifeq ($(4):$$($(2)_NEEDS_HOST_PYTHON),host:python3)
$(2)_DEPENDENCIES += $$(if $$(filter host-python3-setuptools,$(1)),,host-python3-setuptools)
else ifeq ($(4):$$($(2)_NEEDS_HOST_PYTHON),host:python2)
$(2)_DEPENDENCIES += $$(if $$(filter host-python-setuptools,$(1)),,host-python-setuptools)
else ifeq ($$(BR2_PACKAGE_PYTHON3),y)
$(2)_DEPENDENCIES += $$(if $$(filter host-python3-setuptools,$(1)),,host-python3-setuptools)
else
$(2)_DEPENDENCIES += $$(if $$(filter host-python-setuptools,$(1)),,host-python-setuptools)
endif
package/pkg-python: use host-python3-setuptools when needed When a package uses "setuptools" as its <pkg>_SETUP_TYPE, we currently add a dependency on host-python-setuptools. This means that: (1) When BR2_PACKAGE_PYTHON=y, the default host Python version is Python 2.x, and host-python-setuptools is installed for host-python. (2) When BR2_PACKAGE_PYTHON3=y, the default host Python version is Python 3.x, and host-python-setuptools is installed for host-python3. (3) When no target Python interpreter is selected, the default host Python version is Python 2.x, and host-python-setuptools is installed for host-python. Situations (1) and (3) are problematic for host Python packages that need Python 3.x. Such packages use <pkg>_NEEDS_HOST_PYTHON = python3, but if they use setuptools as their setup type, they will not find setuptools installed for host-python3 in situations (1) and (3) described above. We currently have a single package that sets <pkg>_NEEDS_HOST_PYTHON = python3: host-meson. host-meson generally works because if setuptools is not found, it falls back to distutils, which is part of the standard Python library. However, if there is a setuptools version installed system-wide, it may be picked up, but may not necessarily be the same version as Buildroot setuptools, potentially causing problems. This commit makes the necessary change to the python-package infrastructure to fix this behavior, by identifying the following cases: - When a host Python package says <pkg>_NEEDS_HOST_PYTHON = python3, then we know it wants setuptools installed for host-python3, so we use host-python3-setuptools. - When a host Python package says <pkg>_NEEDS_HOST_PYTHON = python2, then we known it wants setuptools installed for host-python, so we use host-python-setuptools. - When BR2_PACKAGE_PYTHON3=y, and we have a target package, or a host package with no NEEDS_HOST_PYTHON option, then we want setuptools installed for host-python3, so we use host-python3-setuptools. - When BR2_PACKAGE_PYTHON=y or no target interpreter is enabled at all, and we have a target package, or a host package with no NEEDS_HOST_PYTHON option, then we want setuptools for host-python, so we use host-python-setuptools. To make this happen, we use host-python3-setuptools introduced in a previous commit, but we also change host-python-setuptools to force its installation for host-python. The latter is needed if you build with BR2_PACKAGE_PYTHON3=y but want to install a Python-based package that has NEEDS_HOST_PYTHON=python2. There is one single package that needs be adjusted following this: lirc-tools, because it is not using the python-package infrastructure. It directly depends on host-python-setuptools, which no longer works because host-python-setuptools now only installs for Python 2.x, while lirc-tools Python binding only supports Python 3.x. Switching to host-python3-setuptools solves this problem. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Asaf Kahlon <asafka7@gmail.com> Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-12-28 18:01:30 +01:00
endif # SETUP_TYPE
pkg-python: support host-python dependency different from the python in the target Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 23:04:42 +01:00
# Python interpreter to use for building the package.
#
# We may want to specify the python interpreter to be used for building a
pkg-python: support host-python dependency different from the python in the target Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 23:04:42 +01:00
# package, especially for host-packages (target packages must be built using
# the same version of the interpreter as the one installed on the target).
#
# So:
# - for target packages, we always use the default python interpreter (which
# is the same version as the one built and installed on the target);
# - for host packages:
# - if *_NEEDS_HOST_PYTHON is not set, then we use use the default
# interperter;
# - otherwise, we use the one requested by *_NEEDS_HOST_PYTHON.
#
ifeq ($(4),target)
$(2)_PYTHON_INTERPRETER = $$(HOST_DIR)/bin/python
pkg-python: support host-python dependency different from the python in the target Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 23:04:42 +01:00
else
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 21:12:24 +02:00
ifeq ($$($(2)_NEEDS_HOST_PYTHON),)
$(2)_PYTHON_INTERPRETER = $$(HOST_DIR)/bin/python
pkg-python: support host-python dependency different from the python in the target Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 23:04:42 +01:00
else
$(2)_PYTHON_INTERPRETER = $$(HOST_DIR)/bin/$$($(2)_NEEDS_HOST_PYTHON)
pkg-python: support host-python dependency different from the python in the target Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 23:04:42 +01:00
endif
endif
#
# Build step. Only define it if not already defined by the package .mk
# file.
#
ifndef $(2)_BUILD_CMDS
define $(2)_BUILD_CMDS
(cd $$($$(PKG)_BUILDDIR)/; \
$$($$(PKG)_BASE_ENV) $$($$(PKG)_ENV) \
pkg-python: support host-python dependency different from the python in the target Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 23:04:42 +01:00
$$($(2)_PYTHON_INTERPRETER) setup.py \
$$($$(PKG)_BASE_BUILD_TGT) \
$$($$(PKG)_BASE_BUILD_OPTS) $$($$(PKG)_BUILD_OPTS))
endef
endif
#
# Host installation step. Only define it if not already defined by the
# package .mk file.
#
ifndef $(2)_INSTALL_CMDS
define $(2)_INSTALL_CMDS
(cd $$($$(PKG)_BUILDDIR)/; \
$$($$(PKG)_BASE_ENV) $$($$(PKG)_ENV) \
pkg-python: support host-python dependency different from the python in the target Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 23:04:42 +01:00
$$($(2)_PYTHON_INTERPRETER) setup.py install \
$$($$(PKG)_BASE_INSTALL_OPTS) $$($$(PKG)_INSTALL_OPTS))
endef
endif
#
# Target installation step. Only define it if not already defined by
# the package .mk file.
#
ifndef $(2)_INSTALL_TARGET_CMDS
define $(2)_INSTALL_TARGET_CMDS
(cd $$($$(PKG)_BUILDDIR)/; \
$$($$(PKG)_BASE_ENV) $$($$(PKG)_ENV) \
python/python3: globalize *.pyc files compilation Currently, each python package (be it the python interpreter package itself or external python modules) is responsible for compiling its .py into .pyc files. Unfortunately, this is not ideal as some packages only install .py files without compiling them into .pyc files. In this case, if the Buildroot configuration specifies to keep only the .pyc files, the .py files are removed and lost. To address this, this commit changes the logic by making the compilation of .pyc files a global operation: the python interpreter packages register a target finalize hook that is in charge of compiling all installed .py files. The *.pyc generation on a per package basis is disabled in the python-package infrastructure by passing the "--no-compile" option to setup.py. The *.pyc generation for the Python interpreter internal modules is disabled through --disable-pyc-build configure option. A small helper script is used to perform the compilation, the purpose of this script is to abort the compilation process if one of the .py file cannot be compiled. It has been provided by Samuel Martin and integrated into this commit. Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Cc: Samuel Martin <s.martin49@gmail.com> [Thomas: - rework for python 3.5 - integrate Samuel proposal that allows to detect compilation failures.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-17 23:19:15 +02:00
$$($(2)_PYTHON_INTERPRETER) setup.py install --no-compile \
$$($$(PKG)_BASE_INSTALL_TARGET_OPTS) \
$$($$(PKG)_INSTALL_TARGET_OPTS))
endef
endif
#
# Staging installation step. Only define it if not already defined by
# the package .mk file.
#
ifndef $(2)_INSTALL_STAGING_CMDS
define $(2)_INSTALL_STAGING_CMDS
(cd $$($$(PKG)_BUILDDIR)/; \
$$($$(PKG)_BASE_ENV) $$($$(PKG)_ENV) \
$$($(2)_PYTHON_INTERPRETER) setup.py install \
$$($$(PKG)_BASE_INSTALL_STAGING_OPTS) \
$$($$(PKG)_INSTALL_STAGING_OPTS))
endef
endif
# Call the generic package infrastructure to generate the necessary
# make targets
$(call inner-generic-package,$(1),$(2),$(3),$(4))
endef
################################################################################
# python-package -- the target generator macro for Python packages
################################################################################
python-package = $(call inner-python-package,$(pkgname),$(call UPPERCASE,$(pkgname)),$(call UPPERCASE,$(pkgname)),target)
host-python-package = $(call inner-python-package,host-$(pkgname),$(call UPPERCASE,host-$(pkgname)),$(call UPPERCASE,$(pkgname)),host)