Skip to contentSkip to conversation

i2c-tools: add support to build python extension

PATCH New Ryan Barnett 3 participants 6 messages Apr 5, 2015

lore
Share & tools
lore

Ryan Barnett

author
#0 lore raw

PATCH 1/1 i2c-tools: add support to build python extension

Add a config option to build the python bindings for i2c-tools - py-smbus. The steps for building the python bindings is the same as the distutil steps that are a part of the python infrastructure.

Signed-off-by Ryan Barnett <[email protected]>
CC Tjeerd Pinkert <[email protected]>
CC Zoltan Gyarmati <[email protected]>
---
 package/i2c-tools/Config.in    | 13 +++++++++++++
 package/i2c-tools/i2c-tools.mk | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 46 insertions(+)
package/i2c-tools/Config.in +13 -0
index e83dbd6..2e537cb 100644
@@ -8,3 +8,16 @@ config BR2_PACKAGE_I2C_TOOLS
 	  EEPROM decoding scripts, and more.
 
 	  http://www.lm-sensors.org/wiki/I2CTools
+
+if BR2_PACKAGE_I2C_TOOLS
+
+config BR2_PACKAGE_I2C_TOOLS_PYSMBUS
+	bool "py-smbus"
+	depends on BR2_PACKAGE_PYTHON
+	help
+	  Python bindings to smbus from the i2c-tools package.
+
+comment "i2c-tools py-smbux depends on python"
+	depends on !BR2_PACKAGE_PYTHON
+
+endif
package/i2c-tools/i2c-tools.mk +33 -0
index 0115e22..f363505 100644
@@ -21,4 +21,37 @@ define I2C_TOOLS_INSTALL_TARGET_CMDS
 	done
 endef
 
+# BASE_ENV taken from PKG_PYTHON_DISTUTILS_ENV in package/pkg-python.mk
+I2C_TOOLS_PYTHON_BASE_ENV = PATH=$(BR_PATH) \
+	CC="$(TARGET_CC)" \
+	CFLAGS="$(TARGET_CFLAGS) -I../include" \
+	LDFLAGS="$(TARGET_LDFLAGS)" \
+	LDSHARED="$(TARGET_CROSS)gcc -shared" \
+	PYTHONPATH="$(if $(BR2_PACKAGE_PYTHON3),$(PYTHON3_PATH),$(PYTHON_PATH))" \
+	_python_sysroot=$(STAGING_DIR) \
+	_python_prefix=/usr \
+	_python_exec_prefix=/usr
+
+# Build/install steps mirror the distutil python package type in the python package
+# infrastructure
+ifeq ($(BR2_PACKAGE_I2C_TOOLS_PYSMBUS),y)
+I2C_TOOLS_DEPENDENCIES += $(if $(BR2_PACKAGE_PYTHON3),host-python3 python3,host-python python)
+
+define I2C_TOOLS_BUILD_PYSMBUS
+	(cd $(@D)/py-smbus;  \
+	$(I2C_TOOLS_PYTHON_BASE_ENV) \
+		$(HOST_DIR)/usr/bin/python setup.py build \
+		--executable=/usr/bin/python)
+endef
+I2C_TOOLS_POST_BUILD_HOOKS += I2C_TOOLS_BUILD_PYSMBUS
+
+define I2C_TOOLS_INSTALL_PYSMBUS
+	(cd $(@D)/py-smbus; \
+	$(I2C_TOOLS_PYTHON_BASE_ENV) \
+		$(HOST_DIR)/usr/bin/python setup.py install \
+		--prefix=$(TARGET_DIR)/usr )
+endef
+I2C_TOOLS_POST_INSTALL_TARGET_HOOKS += I2C_TOOLS_INSTALL_PYSMBUS
+endif
+
 $(eval $(generic-package))
Signature · 1 line
1.9.1
#1 lore raw

PATCH 1/1 i2c-tools: add support to build python extension

Dear Ryan Barnett,

Quoted 3 lines · Ryan Barnett

Add a config option to build the python bindings for i2c-tools - py-smbus. The steps for building the python bindings is the same as the distutil steps that are a part of the python infrastructure.

Yeah, it's a bit sad that we can't re-use the Python package infrastructure is.

I think we discussed this during the Buildroot Developers Meeting, though I can't find any reference to this. Cc'ing Arnout.

So essentially, we have two choices:

* Have separate packages for the C/C++ library and the Python bindings. Like is done today for protobuf + python-protobuf. One problem is how to share the VERSION / SITE / SOURCE variables. The other problem is that people don't necessarily notice when bumping a package version. But the plus side is that we can re-use the python package infrastructure.

* Use one single package. Makes it trivial to share VERSION / SITE / SOURCE, no possible omission when bumping. But the down-side is that we cannot re-use the python package infra.

Maybe we should take the second approach, but adjust a bit the python package infra to make it easier for packages not using the infra to use some of its variables?

Quoted 8 lines
package/i2c-tools/i2c-tools.mk +0 -0
index 0115e22..f363505 100644
@@ -21,4 +21,37 @@ define I2C_TOOLS_INSTALL_TARGET_CMDS
 	done
 endef

package/i2c-tools/i2c-tools.mk define I2C_TOOLS_INSTALL_TARGET_CMDS · line 33

Quoted 10 lines
package/i2c-tools/i2c-tools.mk +10 -0
+# BASE_ENV taken from PKG_PYTHON_DISTUTILS_ENV in package/pkg-python.mk
+I2C_TOOLS_PYTHON_BASE_ENV = PATH=$(BR_PATH) \
+	CC="$(TARGET_CC)" \
+	CFLAGS="$(TARGET_CFLAGS) -I../include" \
+	LDFLAGS="$(TARGET_LDFLAGS)" \
+	LDSHARED="$(TARGET_CROSS)gcc -shared" \
+	PYTHONPATH="$(if $(BR2_PACKAGE_PYTHON3),$(PYTHON3_PATH),$(PYTHON_PATH))" \
+	_python_sysroot=$(STAGING_DIR) \
+	_python_prefix=/usr \
+	_python_exec_prefix=/usr

What about:

I2C_TOOLS_PYTHON_BASE_ENV = \
	$(PKG_PYTHON_DISTUTILS_ENV) \
	CFLAGS="$(TARGET_CFLAGS) -I../include"

this way we re-use a part of the Python package infra.

package/i2c-tools/i2c-tools.mk define I2C_TOOLS_INSTALL_TARGET_CMDS · line 38

Quoted 4 lines
package/i2c-tools/i2c-tools.mk +4 -0
+# Build/install steps mirror the distutil python package type in the python package
+# infrastructure
+ifeq ($(BR2_PACKAGE_I2C_TOOLS_PYSMBUS),y)
+I2C_TOOLS_DEPENDENCIES += $(if $(BR2_PACKAGE_PYTHON3),host-python3 python3,host-python python)

I know we're doing that in pkg-python.mk, but I'm not sure why. I believe something like:

I2C_TOOLS_DEPENDENCIES += $(if $(BR2_PACKAGE_PYTHON3),python3,python)

is sufficient, since pythonX depends on host-pythonX.

package/i2c-tools/i2c-tools.mk define I2C_TOOLS_INSTALL_TARGET_CMDS · line 44

Quoted 5 lines
package/i2c-tools/i2c-tools.mk +5 -0
+define I2C_TOOLS_BUILD_PYSMBUS
+	(cd $(@D)/py-smbus;  \
+	$(I2C_TOOLS_PYTHON_BASE_ENV) \
+		$(HOST_DIR)/usr/bin/python setup.py build \
+		--executable=/usr/bin/python)

Maybe use PKG_PYTHON_DISTUTILS_BUILD_OPTS

package/i2c-tools/i2c-tools.mk define I2C_TOOLS_INSTALL_TARGET_CMDS · line 52

Quoted 8 lines
package/i2c-tools/i2c-tools.mk +8 -0
+endef
+I2C_TOOLS_POST_BUILD_HOOKS += I2C_TOOLS_BUILD_PYSMBUS
+
+define I2C_TOOLS_INSTALL_PYSMBUS
+	(cd $(@D)/py-smbus; \
+	$(I2C_TOOLS_PYTHON_BASE_ENV) \
+		$(HOST_DIR)/usr/bin/python setup.py install \
+		--prefix=$(TARGET_DIR)/usr )

And PKG_PYTHON_DISTUTILS_INSTALL_TARGET_OPTS

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#2 lore raw

PATCH 1/1 i2c-tools: add support to build python extension

Thomas,

Quoted 22 lines · Thomas Petazzoni

Dear Ryan Barnett,

Quoted 3 lines · Ryan Barnett

Add a config option to build the python bindings for i2c-tools - py-smbus. The steps for building the python bindings is the same as the distutil steps that are a part of the python infrastructure.

Yeah, it's a bit sad that we can't re-use the Python package infrastructure is.

I think we discussed this during the Buildroot Developers Meeting, though I can't find any reference to this. Cc'ing Arnout.

So essentially, we have two choices:

* Have separate packages for the C/C++ library and the Python bindings. Like is done today for protobuf + python-protobuf. One problem is how to share the VERSION / SITE / SOURCE variables. The other problem is that people don't necessarily notice when bumping a package version. But the plus side is that we can re-use the python package infrastructure.

Quoted 7 lines

* Use one single package. Makes it trivial to share VERSION / SITE / SOURCE, no possible omission when bumping. But the down-side is that we cannot re-use the python package infra.

Maybe we should take the second approach, but adjust a bit the python package infra to make it easier for packages not using the infra to use some of its variables?

I too prefer the second approach. I don't have any ideas though on how to make it easier to take advantage of the python package infra though. Using the variables from the pkg-python.mk will simplify things a bit.

Quoted 21 lines
Quoted 8 lines
package/i2c-tools/i2c-tools.mk +0 -0
index 0115e22..f363505 100644
@@ -21,4 +21,37 @@ define I2C_TOOLS_INSTALL_TARGET_CMDS
      done
 endef

package/i2c-tools/i2c-tools.mk define I2C_TOOLS_INSTALL_TARGET_CMDS · line 33

Quoted 10 lines
package/i2c-tools/i2c-tools.mk +10 -0
+# BASE_ENV taken from PKG_PYTHON_DISTUTILS_ENV in package/pkg-python.mk
+I2C_TOOLS_PYTHON_BASE_ENV = PATH=$(BR_PATH) \
+     CC="$(TARGET_CC)" \
+     CFLAGS="$(TARGET_CFLAGS) -I../include" \
+     LDFLAGS="$(TARGET_LDFLAGS)" \
+     LDSHARED="$(TARGET_CROSS)gcc -shared" \
+     PYTHONPATH="$(if $(BR2_PACKAGE_PYTHON3),$(PYTHON3_PATH),$(PYTHON_PATH))" \
+     _python_sysroot=$(STAGING_DIR) \
+     _python_prefix=/usr \
+     _python_exec_prefix=/usr

What about:

Quoted 5 lines
I2C_TOOLS_PYTHON_BASE_ENV = \
        $(PKG_PYTHON_DISTUTILS_ENV) \
        CFLAGS="$(TARGET_CFLAGS) -I../include"

this way we re-use a part of the Python package infra.

Agreed. Will the second definition override the definition from PKG_PYTHON_DISTUTILS_ENV?

Quoted 9 lines

package/i2c-tools/i2c-tools.mk define I2C_TOOLS_INSTALL_TARGET_CMDS · line 38

Quoted 5 lines
package/i2c-tools/i2c-tools.mk +4 -0
+# Build/install steps mirror the distutil python package type in the python package
+# infrastructure
+ifeq ($(BR2_PACKAGE_I2C_TOOLS_PYSMBUS),y)
+I2C_TOOLS_DEPENDENCIES += $(if $(BR2_PACKAGE_PYTHON3),host-python3 python3,host-python python)

I know we're doing that in pkg-python.mk, but I'm not sure why. I believe something like:

Quoted 3 lines

I2C_TOOLS_DEPENDENCIES += $(if $(BR2_PACKAGE_PYTHON3),python3,python)

is sufficient, since pythonX depends on host-pythonX.

Agree will simplify. Should I sent a second patch to do this too in pkg-python.mk?

Quoted 7 lines

package/i2c-tools/i2c-tools.mk define I2C_TOOLS_INSTALL_TARGET_CMDS · line 44

Quoted 5 lines
package/i2c-tools/i2c-tools.mk +5 -0
+define I2C_TOOLS_BUILD_PYSMBUS
+     (cd $(@D)/py-smbus;  \
+     $(I2C_TOOLS_PYTHON_BASE_ENV) \
+             $(HOST_DIR)/usr/bin/python setup.py build \
+             --executable=/usr/bin/python)

Maybe use PKG_PYTHON_DISTUTILS_BUILD_OPTS

Agree.

Quoted 10 lines

package/i2c-tools/i2c-tools.mk define I2C_TOOLS_INSTALL_TARGET_CMDS · line 52

Quoted 8 lines
package/i2c-tools/i2c-tools.mk +8 -0
+endef
+I2C_TOOLS_POST_BUILD_HOOKS += I2C_TOOLS_BUILD_PYSMBUS
+
+define I2C_TOOLS_INSTALL_PYSMBUS
+     (cd $(@D)/py-smbus; \
+     $(I2C_TOOLS_PYTHON_BASE_ENV) \
+             $(HOST_DIR)/usr/bin/python setup.py install \
+             --prefix=$(TARGET_DIR)/usr )

And PKG_PYTHON_DISTUTILS_INSTALL_TARGET_OPTS

Agree.

Will be sending a v2 here shortly.

Thanks,
-Ryan

#3 lore raw

PATCH 1/1 i2c-tools: add support to build python extension

In reply to Ryan Barnett

Hi Ryan,

Quoted 17 lines · Ryan Barnett

Add a config option to build the python bindings for i2c-tools - py-smbus. The steps for building the python bindings is the same as the distutil steps that are a part of the python infrastructure.

Signed-off-by Ryan Barnett <[email protected]>
CC Tjeerd Pinkert <[email protected]>
CC Zoltan Gyarmati <[email protected]>
---
 package/i2c-tools/Config.in    | 13 +++++++++++++
 package/i2c-tools/i2c-tools.mk | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 46 insertions(+)
package/i2c-tools/Config.in +0 -0
index e83dbd6..2e537cb 100644

package/i2c-tools/Config.in config BR2_PACKAGE_I2C_TOOLS · line 14

Quoted 7 lines
package/i2c-tools/Config.in +4 -0
@@ -8,3 +8,16 @@ config BR2_PACKAGE_I2C_TOOLS
 	  EEPROM decoding scripts, and more.
 
 	  http://www.lm-sensors.org/wiki/I2CTools
+
+if BR2_PACKAGE_I2C_TOOLS
+
+config BR2_PACKAGE_I2C_TOOLS_PYSMBUS

I don't think another config option is necessary. The size of i2c-tools python binding is negligible when compared to the size of python itself.

package/i2c-tools/Config.in config BR2_PACKAGE_I2C_TOOLS · line 16

Quoted 2 lines
package/i2c-tools/Config.in +2 -0
+	bool "py-smbus"
+	depends on BR2_PACKAGE_PYTHON

This seems to indicate that only python2 is supported ...

[...]

package/i2c-tools/Config.in config BR2_PACKAGE_I2C_TOOLS · line 18

Quoted 2 lines
package/i2c-tools/Config.in +2 -0
+ifeq ($(BR2_PACKAGE_I2C_TOOLS_PYSMBUS),y)
+I2C_TOOLS_DEPENDENCIES += $(if $(BR2_PACKAGE_PYTHON3),host-python3 python3,host-python python)

But this assumes that both python2 and python3 are supported. Which one is correct?

Also, there is no need to explicitly list python host variants. Target python packages already depend on their corresponding host packages.

baruch

Signature · 3 lines
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
author
#4 lore raw

PATCH 1/1 i2c-tools: add support to build python extension

Baruch,

Quoted 22 lines · Baruch Siach

Hi Ryan,

Quoted 19 lines · Ryan Barnett

Add a config option to build the python bindings for i2c-tools - py-smbus. The steps for building the python bindings is the same as the distutil steps that are a part of the python infrastructure.

Signed-off-by Ryan Barnett <[email protected]>
CC Tjeerd Pinkert <[email protected]>
CC Zoltan Gyarmati <[email protected]>
---
 package/i2c-tools/Config.in    | 13 +++++++++++++
 package/i2c-tools/i2c-tools.mk | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 46 insertions(+)
package/i2c-tools/Config.in +0 -0
index e83dbd6..2e537cb 100644
@@ -8,3 +8,16 @@ config BR2_PACKAGE_I2C_TOOLS
        EEPROM decoding scripts, and more.
Quoted 8 lines

package/i2c-tools/Config.in config BR2_PACKAGE_I2C_TOOLS · line 14

Quoted 5 lines
package/i2c-tools/Config.in +4 -0
        http://www.lm-sensors.org/wiki/I2CTools
+
+if BR2_PACKAGE_I2C_TOOLS
+
+config BR2_PACKAGE_I2C_TOOLS_PYSMBUS

I don't think another config option is necessary. The size of i2c-tools python binding is negligible when compared to the size of python itself.

Good point. So do I still keep a comment there about py-smbus not being enabled unless python is selected? Otherwise someone might not know that i2c-tools has the python bindings which is why I had the config option to begin with.

Quoted 6 lines

package/i2c-tools/Config.in config BR2_PACKAGE_I2C_TOOLS · line 16

Quoted 3 lines
package/i2c-tools/Config.in +2 -0
+     bool "py-smbus"
+     depends on BR2_PACKAGE_PYTHON

This seems to indicate that only python2 is supported ...

Quoted 7 lines

[...]

package/i2c-tools/Config.in

Quoted 2 lines
package/i2c-tools/Config.in +2 -0
+ifeq ($(BR2_PACKAGE_I2C_TOOLS_PYSMBUS),y)
+I2C_TOOLS_DEPENDENCIES += $(if $(BR2_PACKAGE_PYTHON3),host-python3 python3,host-python python)

But this assumes that both python2 and python3 are supported. Which one is correct?

I believe both are support so I will need to confirm and update my config option to support either one.

Quoted 2 lines

Also, there is no need to explicitly list python host variants. Target python packages already depend on their corresponding host packages.

Already have implemented based off of Thomas P comments.

Thanks,
-Ryan

#5 lore raw

PATCH 1/1 i2c-tools: add support to build python extension

Hi Ryan,

Quoted 11 lines · Ryan Barnett
Quoted 5 lines · Baruch Siach
Quoted 1 line · Ryan Barnett

+config BR2_PACKAGE_I2C_TOOLS_PYSMBUS

I don't think another config option is necessary. The size of i2c-tools python binding is negligible when compared to the size of python itself.

Good point. So do I still keep a comment there about py-smbus not being enabled unless python is selected? Otherwise someone might not know that i2c-tools has the python bindings which is why I had the config option to begin with.

I think it is reasonable to expect users looking for a python binding to enable python itself first.

baruch

Signature · 3 lines
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -