From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] i2c-tools: add support to build python extension
Date: Sun, 5 Apr 2015 21:00:06 +0200 [thread overview]
Message-ID: <20150405210006.12d3e201@free-electrons.com> (raw)
In-Reply-To: <1428259675-7116-1-git-send-email-ryanbarnett3@gmail.com>
Dear Ryan Barnett,
On Sun, 5 Apr 2015 13:47:55 -0500, Ryan Barnett wrote:
> 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?
> diff --git a/package/i2c-tools/i2c-tools.mk b/package/i2c-tools/i2c-tools.mk
> index 0115e22..f363505 100644
> --- a/package/i2c-tools/i2c-tools.mk
> +++ b/package/i2c-tools/i2c-tools.mk
> @@ -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
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.
> +# 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.
> +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
> +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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-04-05 19:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-05 18:47 [Buildroot] [PATCH 1/1] i2c-tools: add support to build python extension Ryan Barnett
2015-04-05 19:00 ` Thomas Petazzoni [this message]
2015-04-05 19:15 ` Ryan Barnett
2015-04-05 19:13 ` Baruch Siach
2015-04-05 19:22 ` Ryan Barnett
2015-04-05 19:35 ` Baruch Siach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150405210006.12d3e201@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox