Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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