Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 3/6] pkg-python: support host-python dependency different from the python in the target
Date: Sat, 29 Mar 2014 12:47:28 +0100	[thread overview]
Message-ID: <20140329114728.GF3227@free.fr> (raw)
In-Reply-To: <1394057085-10399-4-git-send-email-s.martin49@gmail.com>

Samuel, All,

On 2014-03-05 23:04 +0100, Samuel Martin spake thusly:
> 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, so build any kind of packages even if

s/so/to/

> 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 add a *_FORCE_HOST_PYTHON variable that can be set either

While we are at it: s/add/adds/

Also, I'd name the variable *_NEEDS_HOST_PYTHON (which is more
meaningfull than FORCE.)

> to 'python2' or 'python3'. This variable can be set by any package
> using the host-python-package infrastructure can set to force the
> python interpreter for the build.

This sentence is grammatically incorrect. s/can set//

> This variable also takes care of
> setting the right host-python dependency.
> 
> This *_FORCE_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 define some tool variable (eg.: SCONS), the variable

s/define/defines/

> should explicitly called the right python interpreter.
> 
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  docs/manual/adding-packages-python.txt |  8 ++++++
>  package/pkg-python.mk                  | 50 +++++++++++++++++++++++++++++++---
>  2 files changed, 54 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/manual/adding-packages-python.txt b/docs/manual/adding-packages-python.txt
> index b8d5331..da97654 100644
> --- a/docs/manual/adding-packages-python.txt
> +++ b/docs/manual/adding-packages-python.txt
> @@ -144,6 +144,14 @@ therefore only use a few of them, or none.
>    setuptools packages) and +HOST_PKG_PYTHON_SETUPTOOLS_INSTALL_OPT+
>    (for host setuptools packages).
>  
> +* +HOST_PYTHON_FOO_FORCE_HOST_PYTHON+, to define the host python
> +  interpreter. The usage of this variable is limited to the host
> +  packages. The two supported value are +python2+ and +python3+.
> +  It will may sure the right host python package is available for

s/may sure/ensure/

> +  the build and will invoke it for the build. If some build steps
> +  are overloaded, the right python interpreter must be explicitly
> +  called in the commands.
> +
>  With the Python infrastructure, all the steps required to build and
>  install the packages are already defined, and they generally work well
>  for most Python-based packages. However, when required, it is still
> diff --git a/package/pkg-python.mk b/package/pkg-python.mk
> index 512ef66..178b494 100644
> --- a/package/pkg-python.mk
> +++ b/package/pkg-python.mk
> @@ -143,11 +143,29 @@ $(2)_DEPENDENCIES ?= $(filter-out host-python host-python3 host-python-setuptool
>  # 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
> -# interpreter on the host.
> +# interpreter on the host, whose version may be enforced by setting
> +# the *_FORCE_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 *_FORCE_HOST_PYTHON is not set, then we depend on use the default
> +#     interperter;
> +#   - otherwise, we depend on the one requested by *_FORCE_HOST_PYTHON.
> +#
>  ifeq ($(4),target)
>  $(2)_DEPENDENCIES += $(if $(BR2_PACKAGE_PYTHON3),host-python3 python3,host-python python)
>  else
> +ifeq ($($(2)_FORCE_HOST_PYTHON),)
>  $(2)_DEPENDENCIES += $(if $(BR2_PACKAGE_PYTHON3),host-python3,host-python)
> +else
> +ifeq ($($(2)_FORCE_HOST_PYTHON),python2)
> +$(2)_DEPENDENCIES += host-python
> +else
> +$(2)_DEPENDENCIES += host-$$($(2)_FORCE_HOST_PYTHON)

If the user makes a typo in the variable value, we'd end up using
host-TYPO and the build may fail. For example, if the user types
'python' instead of 'python3', we'll end up using python2.

I thionk we should explicitly check for (empty), 'python2' or 'python3',
and abort on any other value:

    ifeq ($($(2)_FORCE_HOST_PYTHON),python2)
    $(2)_DEPENDENCIES += host-python
    else ifeq ($($(2)_FORCE_HOST_PYTHON),python3)
    $(2)_DEPENDENCIES += host-python3
    else
    $$(error Incorrect value '$($(2)_FORCE_HOST_PYTHON)' for $(2)_FORCE_HOST_PYTHON)
    endif
    endif

> +endif
> +endif
>  endif
>  
>  # Setuptools based packages will need host-python-setuptools (both
> @@ -161,6 +179,30 @@ $(2)_DEPENDENCIES += host-python-setuptools
>  endif
>  endif
>  
> +# Python interpreter to use for building the package.
> +#
> +# We may want to specify the python interpreter toi be used for building a
> +# 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 *_FORCE_HOST_PYTHON is not set, then we use use the default
> +#     interperter;
> +#   - otherwise, we use the one requested by *_FORCE_HOST_PYTHON.
> +#
> +ifeq ($(4),target)
> +$(2)_PYTHON_INTERPRETER = $(HOST_DIR)/usr/bin/python
> +else
> +ifeq ($($(2)_FORCE_HOST_PYTHON),)
> +$(2)_PYTHON_INTERPRETER = $(HOST_DIR)/usr/bin/python
> +else
> +$(2)_PYTHON_INTERPRETER = $(HOST_DIR)/usr/bin/$($(2)_FORCE_HOST_PYTHON)

But we do not need to check here, as it would have been done above.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2014-03-29 11:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05 22:04 [Buildroot] [PATCH 0/6] host-python2 hard dependency Samuel Martin
2014-03-05 22:04 ` [Buildroot] [PATCH 1/6] python: rework python symlinks installation Samuel Martin
2014-03-29 11:05   ` Yann E. MORIN
2014-03-05 22:04 ` [Buildroot] [PATCH 2/6] python3: " Samuel Martin
2014-03-29 11:23   ` Yann E. MORIN
2014-03-05 22:04 ` [Buildroot] [PATCH 3/6] pkg-python: support host-python dependency different from the python in the target Samuel Martin
2014-03-29 11:47   ` Yann E. MORIN [this message]
2014-03-29 13:26     ` Thomas Petazzoni
2014-03-29 13:58       ` Yann E. MORIN
2014-03-05 22:04 ` [Buildroot] [PATCH 4/6] scons: force host-python dependency to be python2 Samuel Martin
2014-03-29 11:50   ` Yann E. MORIN
2014-03-05 22:04 ` [Buildroot] [PATCH 5/6] python-m2crypto: requires host-python2 Samuel Martin
2014-03-29 11:51   ` Yann E. MORIN
2014-03-05 22:04 ` [Buildroot] [PATCH 6/6] crda: override python interperter Samuel Martin
2014-03-29 11:56   ` Yann E. MORIN
2014-04-05 15:42 ` [Buildroot] [PATCH 0/6] host-python2 hard dependency Thomas Petazzoni

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=20140329114728.GF3227@free.fr \
    --to=yann.morin.1998@free.fr \
    --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