python: clean up host version logic.
cover python: clean up host version logic.
Currently, packages that rely on host-python, and are compatible with both python2 and 3, only build python3 if python3 is selected for the target.
This causes a problem in the following scenario:
- A user does not have a target python selected.
- Package A depends on host-python3
- Package B is compatible with host-python and host-python3
In this scenario, host-python is not needed, as package A and B are both compatible with python3. However; both host-python and host-python3 will be built because no target-python has been selected.
To fix this, the following patch series introduces a few minimal changes that will allow the user to manually select a host version of python. (Note: I have changed only the packages that I personally use and have tested.)
Adam Duskett (8):
python: add host-entry
python3: add host-entry
python-setuptools: check host-python version
pkg-waf.mk: check host-python version
ninja: check host-python version
libselinux: check host-python version
setools: check host-python version
libselinux: check host-python version
package/Config.in.host | 2 ++ package/libselinux/libselinux.mk | 2 +- package/libsemanage/libsemanage.mk | 2 +- package/ninja/ninja.mk | 2 +- package/pkg-waf.mk | 20 +++++++++++++------- package/python-setuptools/python-setuptools.mk | 10 +++++++++- package/python/Config.in.host | 6 ++++++ package/python3/Config.in.host | 6 ++++++ package/setools/setools.mk | 6 ++++++ 9 files changed, 45 insertions(+), 11 deletions(-) create mode 100644 package/python/Config.in.host create mode 100644 package/python3/Config.in.host
Signature · 1 line
2.14.3
PATCH 1/8 python: add selectable host entry
Add a user selectable entry to build python2 as a host package.
--- package/Config.in.host | 1 + package/python/Config.in.host | 6 ++++++ 2 files changed, 7 insertions(+) create mode 100644 package/python/Config.in.host
package/Config.in.host +1 -0
@@ -41,6 +41,7 @@ menu "Host utilities" source "package/pkgconf/Config.in.host" source "package/pru-software-support/Config.in.host" source "package/pwgen/Config.in.host" + source "package/python/Config.in.host" source "package/python-lxml/Config.in.host" source "package/python-six/Config.in.host" source "package/qemu/Config.in.host"
package/python/Config.in.host new file +6 -0
@@ -0,0 +1,6 @@ +config BR2_PACKAGE_HOST_PYTHON + bool "host python" + help + The python language interpreter. + + http://www.python.org/
Signature · 1 line
2.14.3
PATCH 2/8 python3: add selectable host entry
In reply to Adam DuskettAdd a user selectable entry to build python3 as a host package.
--- package/Config.in.host | 1 + package/python3/Config.in.host | 6 ++++++ 2 files changed, 7 insertions(+) create mode 100644 package/python3/Config.in.host
package/Config.in.host +1 -0
@@ -42,6 +42,7 @@ menu "Host utilities" source "package/pru-software-support/Config.in.host" source "package/pwgen/Config.in.host" source "package/python/Config.in.host" + source "package/python3/Config.in.host" source "package/python-lxml/Config.in.host" source "package/python-six/Config.in.host" source "package/qemu/Config.in.host"
package/python3/Config.in.host new file +6 -0
@@ -0,0 +1,6 @@ +config BR2_PACKAGE_HOST_PYTHON3 + bool "host python3" + help + The python language interpreter. + + http://www.python.org/
Signature · 1 line
2.14.3
PATCH 3/8 python-setuptools: check host-python version
In reply to Adam Duskettpython-setuptools is compatible with both python2 and python3, as such, there is no need to force python2 as a dependency.
--- package/python-setuptools/python-setuptools.mk | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
package/python-setuptools/python-setuptools.mk +9 -1
@@ -10,10 +10,18 @@ PYTHON_SETUPTOOLS_LICENSE = MIT PYTHON_SETUPTOOLS_LICENSE_FILES = LICENSE PYTHON_SETUPTOOLS_SETUP_TYPE = setuptools +ifeq ($(BR2_PACKAGE_HOST_PYTHON3),y) +HOST_PYTHON_SETUPTOOLS_NEEDS_HOST_PYTHON += python3 +HOST_PYTHON_SETUPTOOLS_PYLIBVER = python$(PYTHON3_VERSION_MAJOR) +else +HOST_PYTHON_SETUPTOOLS_NEEDS_HOST_PYTHON += python +HOST_PYTHON_SETUPTOOLS_PYLIBVER = python$(PYTHON_VERSION_MAJOR) +endif + # recent setuptools versions require bootstrap.py to be invoked # before the standard setup process. define PYTHON_SETUPTOOLS_RUN_BOOTSTRAP - cd $(@D) && $(HOST_DIR)/bin/python ./bootstrap.py + cd $(@D) && $(HOST_DIR)/bin/$(HOST_PYTHON_SETUPTOOLS_PYLIBVER) ./bootstrap.py endef PYTHON_SETUPTOOLS_PRE_CONFIGURE_HOOKS = PYTHON_SETUPTOOLS_RUN_BOOTSTRAP
Signature · 1 line
2.14.3
PATCH 3/8 python-setuptools: check host-python version
Hello,
Quoted 13 lines · Adam Duskett
python-setuptools is compatible with both python2 and python3, as such, there is no need to force python2 as a dependency.
Signed-off-by Adam Duskett <[email protected]>--- package/python-setuptools/python-setuptools.mk | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)package/python-setuptools/python-setuptools.mk +0
-0
package/python-setuptools/python-setuptools.mk PYTHON_SETUPTOOLS_LICENSE = MIT · line 19
Quoted 10 lines
package/python-setuptools/python-setuptools.mk +7
-0@@ -10,10 +10,18 @@ PYTHON_SETUPTOOLS_LICENSE = MIT PYTHON_SETUPTOOLS_LICENSE_FILES = LICENSE PYTHON_SETUPTOOLS_SETUP_TYPE = setuptools +ifeq ($(BR2_PACKAGE_HOST_PYTHON3),y) +HOST_PYTHON_SETUPTOOLS_NEEDS_HOST_PYTHON += python3 +HOST_PYTHON_SETUPTOOLS_PYLIBVER = python$(PYTHON3_VERSION_MAJOR) +else +HOST_PYTHON_SETUPTOOLS_NEEDS_HOST_PYTHON += python +HOST_PYTHON_SETUPTOOLS_PYLIBVER = python$(PYTHON_VERSION_MAJOR) +endif
So, now, if the user selects:
BR2_PACKAGE_PYTHON=y
BR2_PACKAGE_PYTHON_ARROW=y
BR2_PACKAGE_HOST_PYTHON3=y
then the build will break. Indeed, since python2 is selected as the Python for the target, python-arrow should be built and installed for python2, so it will expect host-python-setuptools to be built and installed for host-python.
But because the user has selected BR2_PACKAGE_HOST_PYTHON3, host-python-setuptools will be installed for host-python3.
So, I believe the build breaks with your change.
Basically the current reasoning of the current Python packaging is:
- The user selects the target version of Python, and from that we derive:
* That we need to build the same Python version for the host
* That all host Python modules should be built installed for that Python version
- Optionally, packages may depend on the other host-python{,3} if they really need that specific Python version. However, we do not support installing third party Python modules for this secondary host Python version.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 3/8 python-setuptools: check host-python version
In reply to Adam Duskettpackage/python-setuptools/python-setuptools.mk PYTHON_SETUPTOOLS_LICENSE = MIT · line 19
Quoted 11 lines · Adam Duskett
python-setuptools is compatible with both python2 and python3, as such, there is no need to force python2 as a dependency.
package/python-setuptools/python-setuptools.mk +7
-0+ifeq ($(BR2_PACKAGE_HOST_PYTHON3),y) +HOST_PYTHON_SETUPTOOLS_NEEDS_HOST_PYTHON += python3 +HOST_PYTHON_SETUPTOOLS_PYLIBVER = python$(PYTHON3_VERSION_MAJOR) +else +HOST_PYTHON_SETUPTOOLS_NEEDS_HOST_PYTHON += python +HOST_PYTHON_SETUPTOOLS_PYLIBVER = python$(PYTHON_VERSION_MAJOR) +endif
From why I see in pkg-python, the default behavior for host packages is to depend on the default interpreter, which is python3 if enabled otherwise python2. Isn't the above block basically doing the same thing? Other than using HOST_PYTHON3 rather than PYTHON3.
But shouldn't this be changed in pkg-python?
Then setting <PKG>_NEEDS_HOST_PYTHON based on why python version is in use could be eliminated, unless the package needs a specific version, which appear to be how it's supposed to work.
PATCH 3/8 python-setuptools: check host-python version
Hello,
Quoted 18 lines · Trent Piepho
package/python-setuptools/python-setuptools.mk PYTHON_SETUPTOOLS_LICENSE = MIT · line 19
Quoted 11 lines · Adam Duskett
python-setuptools is compatible with both python2 and python3, as such, there is no need to force python2 as a dependency.
package/python-setuptools/python-setuptools.mk +7
-0+ifeq ($(BR2_PACKAGE_HOST_PYTHON3),y) +HOST_PYTHON_SETUPTOOLS_NEEDS_HOST_PYTHON += python3 +HOST_PYTHON_SETUPTOOLS_PYLIBVER = python$(PYTHON3_VERSION_MAJOR) +else +HOST_PYTHON_SETUPTOOLS_NEEDS_HOST_PYTHON += python +HOST_PYTHON_SETUPTOOLS_PYLIBVER = python$(PYTHON_VERSION_MAJOR) +endifFrom why I see in pkg-python, the default behavior for host packages is to depend on the default interpreter, which is python3 if enabled otherwise python2. Isn't the above block basically doing the same thing? Other than using
HOST_PYTHON3rather than PYTHON3.
Quoted 5 lines
But shouldn't this be changed in pkg-python?
Then setting <PKG>_NEEDS_HOST_PYTHON based on why python version is in use could be eliminated, unless the package needs a specific version, which appear to be how it's supposed to work.
See my reply to this patch, which explains why it is (IMO) broken.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 3/8 python-setuptools: check host-python version
Quoted 16 lines · Thomas Petazzoni
Quoted 15 lines · Trent Piepho
package/python-setuptools/python-setuptools.mk PYTHON_SETUPTOOLS_LICENSE = MIT · line 19
Quoted 8 lines · Adam Duskett
package/python-setuptools/python-setuptools.mk +7
-0+ifeq ($(BR2_PACKAGE_HOST_PYTHON3),y) +HOST_PYTHON_SETUPTOOLS_NEEDS_HOST_PYTHON += python3 +HOST_PYTHON_SETUPTOOLS_PYLIBVER = python$(PYTHON3_VERSION_MAJOR) +else +HOST_PYTHON_SETUPTOOLS_NEEDS_HOST_PYTHON += python +HOST_PYTHON_SETUPTOOLS_PYLIBVER = python$(PYTHON_VERSION_MAJOR) +endifFrom why I see in pkg-python, the default behavior for host packages is to depend on the default interpreter, which is python3 if enabled otherwise python2. Isn't the above block basically doing the same thing? Other than using
HOST_PYTHON3rather than PYTHON3.
Quoted 8 lines
Quoted 5 lines
But shouldn't this be changed in pkg-python?
Then setting <PKG>_NEEDS_HOST_PYTHON based on why python version is in use could be eliminated, unless the package needs a specific version, which appear to be how it's supposed to work.
See my reply to this patch, which explains why it is (IMO) broken.
If I understand correctly, the fundamental problem is that Adam's patch allows for simultaneously enabling both host python2 and host python3 and building host python packages using both python versions or a version different than the target python version.
But I think Adam pointed out a real flaw that can be fixed. It's caused problems for me as well.
The issue is that the host python version is linked to the target python version. Which is fine, if there is a target python. But the logic fails if there is no target python.
Right now, one gets this:
Target Python 2 -> Host Python 2
Target Python 3 -> Host Python 3
No Target Python -> Host Python 2
I'd like to build host python 3 utilities and don't have python on the target. Can't see a way to configure buildroot to do that. I can add a build dep on host-python3 and get the interpreter built, but I can't make a host-python-package using python3.
I think this could be fixed by making host python config options, which are forced by the target python configs, so that host python can only be selected manually if no target python is enabled.
Packages that want to depend on host python should use the host python config to select which python to depends on, rather than the target python config as they do now. If target python is enabled, then host python == target python so there is no change. But without target python it will be possible to build select either host-python3 or host- python as the python version to be used by host-python-setuptools.
PATCH 3/8 python-setuptools: check host-python version
Hello,
Quoted 4 lines · Trent Piepho
If I understand correctly, the fundamental problem is that Adam's patch allows for simultaneously enabling both host python2 and host python3 and building host python packages using both python versions or a version different than the target python version.
Correct.
Quoted 11 lines
But I think Adam pointed out a real flaw that can be fixed. It's caused problems for me as well.
The issue is that the host python version is linked to the target python version. Which is fine, if there is a target python. But the logic fails if there is no target python.
Right now, one gets this:
Target Python 2 -> Host Python 2
Target Python 3 -> Host Python 3
No Target Python -> Host Python 2
Absolutely.
Quoted 9 lines
I'd like to build host python 3 utilities and don't have python on the target. Can't see a way to configure buildroot to do that. I can add a build dep on host-python3 and get the interpreter built, but I can't make a host-python-package using python3.
I think this could be fixed by making host python config options, which are forced by the target python configs, so that host python can only be selected manually if no target python is enabled.
Quoted 6 lines
Packages that want to depend on host python should use the host python config to select which python to depends on, rather than the target python config as they do now. If target python is enabled, then host python == target python so there is no change. But without target python it will be possible to build select either host-python3 or host- python as the python version to be used by host-python-setuptools.
Yes, this would be possible. Feel free to make a proposal in this direction.
In general, we have already discussed several times adding Config.in options for all host packages. They would be hidden options for most of the packages, but they would still be visible for some packages (like we have today in Config.in.host).
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 4/8 pkg-waf.mk: check host-python version
In reply to Adam Duskettwaf is compatible with both python2 and python3. Now that there are host entries for python, the make logic can be changed to check if host-python3 has been selected, and if so, depend on it instead of explicitly depending only on python2.
--- package/pkg-waf.mk | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-)
package/pkg-waf.mk +13 -7
@@ -36,9 +36,6 @@ define inner-waf-package -# We need host-python to run waf -$(2)_DEPENDENCIES += host-python - $(2)_NEEDS_EXTERNAL_WAF ?= NO # If the package does not have its own waf, use our own.
@@ -49,6 +46,15 @@ else $(2)_WAF = ./waf endif +# We need a host-python to run waf +ifeq ($(BR2_PACKAGE_HOST_PYTHON3),y) +$(2)_DEPENDENCIES += host-python3 +$(2)_WAF_PYTHON_PATH ?= $$(HOST_DIR)/bin/python3 +else +$(2)_DEPENDENCIES += host-python +$(2)_WAF_PYTHON_PATH ?= $$(HOST_DIR)/bin/python2 +endif + $(2)_BUILD_OPTS ?= $(2)_INSTALL_STAGING_OPTS ?= $(2)_INSTALL_TARGET_OPTS ?=
@@ -63,7 +69,7 @@ define $(2)_CONFIGURE_CMDS cd $$(@D) && \ $$(TARGET_CONFIGURE_OPTS) \ $$($(2)_CONF_ENV) \ - $$(HOST_DIR)/bin/python2 $$($(2)_WAF) configure \ + $$($(2)_WAF_PYTHON_PATH) $$($(2)_WAF) configure \ --prefix=/usr \ --libdir=/usr/lib \ $$($(2)_CONF_OPTS) \
@@ -78,7 +84,7 @@ endif ifndef $(2)_BUILD_CMDS define $(2)_BUILD_CMDS cd $$(@D) && \ - $$(TARGET_MAKE_ENV) $$(HOST_DIR)/bin/python2 $$($(2)_WAF) \ + $$(TARGET_MAKE_ENV) $$($(2)_WAF_PYTHON_PATH) $$($(2)_WAF) \ build -j $$(PARALLEL_JOBS) $$($(2)_BUILD_OPTS) \ $$($(2)_WAF_OPTS) endef
@@ -91,7 +97,7 @@ endif ifndef $(2)_INSTALL_STAGING_CMDS define $(2)_INSTALL_STAGING_CMDS cd $$(@D) && \ - $$(TARGET_MAKE_ENV) $$(HOST_DIR)/bin/python2 $$($(2)_WAF) \ + $$(TARGET_MAKE_ENV) $$($(2)_WAF_PYTHON_PATH) $$($(2)_WAF) \ install --destdir=$$(STAGING_DIR) \ $$($(2)_INSTALL_STAGING_OPTS) \ $$($(2)_WAF_OPTS)
@@ -105,7 +111,7 @@ endif ifndef $(2)_INSTALL_TARGET_CMDS define $(2)_INSTALL_TARGET_CMDS cd $$(@D) && \ - $$(TARGET_MAKE_ENV) $$(HOST_DIR)/bin/python2 $$($(2)_WAF) \ + $$(TARGET_MAKE_ENV) $$($(2)_WAF_PYTHON_PATH) $$($(2)_WAF) \ install --destdir=$$(TARGET_DIR) \ $$($(2)_INSTALL_TARGET_OPTS) \ $$($(2)_WAF_OPTS)
Signature · 1 line
2.14.3
PATCH 5/8 ninja: check host-python version
In reply to Adam DuskettCheck if host-python3 is selected instead of target-python3.
--- package/ninja/ninja.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
package/ninja/ninja.mk +1 -1
@@ -9,7 +9,7 @@ NINJA_SITE = $(call github,ninja-build,ninja,$(NINJA_VERSION)) NINJA_LICENSE = Apache-2.0 NINJA_LICENSE_FILES = COPYING -HOST_NINJA_DEPENDENCIES = $(if $(BR2_PACKAGE_PYTHON3),host-python3,host-python) +HOST_NINJA_DEPENDENCIES = $(if $(BR2_PACKAGE_HOST_PYTHON3),host-python3,host-python) define HOST_NINJA_BUILD_CMDS (cd $(@D); ./configure.py --bootstrap)
Signature · 1 line
2.14.3
PATCH 6/8 libselinux: check host-python version
In reply to Adam DuskettCheck if host-python3 is selected instead of target-python3.
--- package/libselinux/libselinux.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
package/libselinux/libselinux.mk +1 -1
@@ -75,7 +75,7 @@ endef HOST_LIBSELINUX_DEPENDENCIES = \ host-libsepol host-pcre host-swig -ifeq ($(BR2_PACKAGE_PYTHON3),y) +ifeq ($(BR2_PACKAGE_HOST_PYTHON3),y) HOST_LIBSELINUX_DEPENDENCIES += host-python3 HOST_LIBSELINUX_PYINC = -I$(HOST_DIR)/include/python$(PYTHON3_VERSION_MAJOR)m/ HOST_LIBSELINUX_PYLIBVER = python$(PYTHON3_VERSION_MAJOR)
Signature · 1 line
2.14.3
PATCH 7/8 setools: check host-python version
In reply to Adam DuskettCheck if host-python3 is selected instead of target-python3.
--- package/setools/setools.mk | 6 ++++++ 1 file changed, 6 insertions(+)
package/setools/setools.mk +6 -0
@@ -20,6 +20,12 @@ SETOOLS_PYLIBVER = python$(PYTHON_VERSION_MAJOR) SETOOLS_DEPENDENCIES += python-enum34 endif +ifeq ($(BR2_PACKAGE_HOST_PYTHON3),y) +HOST_SETOOLS_NEEDS_HOST_PYTHON += python3 +else +HOST_SETOOLS_NEEDS_HOST_PYTHON += python +endif + define SETOOLS_FIX_SETUP # By default, setup.py will look for libsepol.a in the host machines # /usr/lib directory. This needs to be changed to the staging directory.
Signature · 1 line
2.14.3
PATCH 8/8 libselinux: check host-python version
In reply to Adam DuskettCheck if host-python3 is selected instead of target-python3.
--- package/libsemanage/libsemanage.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
package/libsemanage/libsemanage.mk +1 -1
@@ -37,7 +37,7 @@ HOST_LIBSEMANAGE_MAKE_OPTS += \ PREFIX=$(HOST_DIR) \ SWIG_LIB="$(HOST_DIR)/share/swig/$(SWIG_VERSION)/" -ifeq ($(BR2_PACKAGE_PYTHON3),y) +ifeq ($(BR2_PACKAGE_HOST_PYTHON3),y) HOST_LIBSEMANAGE_DEPENDENCIES += host-python3 HOST_LIBSEMANAGE_MAKE_OPTS += \ PYINC="-I$(HOST_DIR)/include/python$(PYTHON3_VERSION_MAJOR)m/" \
Signature · 1 line
2.14.3
cover python: clean up host version logic.
In reply to Adam DuskettHello,
Quoted 9 lines · Adam Duskett
Currently, packages that rely on host-python, and are compatible with both python2 and 3, only build python3 if python3 is selected for the target.
This causes a problem in the following scenario:
- A user does not have a target python selected.
- Package A depends on host-python3
- Package B is compatible with host-python and host-python3
Quoted 7 lines
In this scenario, host-python is not needed, as package A and B are both compatible with python3. However; both host-python and host-python3 will be built because no target-python has been selected.
To fix this, the following patch series introduces a few minimal changes that will allow the user to manually select a host version of python. (Note: I have changed only the packages that I personally use and have tested.)
I will have to think a lot to fully grasp the potential consequences of your changes.
However, there is one thing that I believe is missing in your patch
series: BR2_PACKAGE_PYTHON3 should select BR2_PACKAGE_HOST_PYTHON3, and BR2_PACKAGE_PYTHON should select BR2_PACKAGE_HOST_PYTHON.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
cover python: clean up host version logic.
Thomas, Adam, All,
On 2018-01-02 21:40 +0100, Thomas Petazzoni spake thusly:
Quoted 18 lines · Adam Duskett
Quoted 9 lines
Currently, packages that rely on host-python, and are compatible with both python2 and 3, only build python3 if python3 is selected for the target.
This causes a problem in the following scenario:
- A user does not have a target python selected.
- Package A depends on host-python3
- Package B is compatible with host-python and host-python3Quoted 7 lines
In this scenario, host-python is not needed, as package A and B are both compatible with python3. However; both host-python and host-python3 will be built because no target-python has been selected.
To fix this, the following patch series introduces a few minimal changes that will allow the user to manually select a host version of python. (Note: I have changed only the packages that I personally use and have tested.)
Quoted 6 lines
I will have to think a lot to fully grasp the potential consequences of your changes.
However, there is one thing that I believe is missing in your patch
series:BR2_PACKAGE_PYTHON3should selectBR2_PACKAGE_HOST_PYTHON3, andBR2_PACKAGE_PYTHONshould selectBR2_PACKAGE_HOST_PYTHON.
Furthermore, I believe the prompt should be hidden, because it does not make sense for the user to actually select the host version for python.
Besides, the current series allows for building both host-python and host-python3 in the same configuration, and we do not support this for now (or we would have made it possible for the target variant too).
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
cover python: clean up host version logic.
Hello,
Quoted 6 lines · Yann E. MORIN
Quoted 3 lines
However, there is one thing that I believe is missing in your patch
series:BR2_PACKAGE_PYTHON3should selectBR2_PACKAGE_HOST_PYTHON3, andBR2_PACKAGE_PYTHONshould selectBR2_PACKAGE_HOST_PYTHON.Furthermore, I believe the prompt should be hidden, because it does not make sense for the user to actually select the host version for python.
If the prompt is not user-selectable, then I don't see the point of the patch series. Indeed, you can already do:
<pkg>_DEPENDENCIES = $(if $(BR2_PACKAGE_PYTHON3),host-python3,host-python)
to use host-python3 if already built as part of the python3 build process, or fallback to host-python otherwise. We already use this construct in a number of places.
Quoted 3 lines
Besides, the current series allows for building both host-python and host-python3 in the same configuration, and we do not support this for now (or we would have made it possible for the target variant too).
Of course we support building both host-python and host-python3. What we don't support is:
- python and python3 in the same configuration
- building third-party host python modules for a host python version different from the selected target python version
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com