[Buildroot] [RFC] python: select vs depends on

[Clayton Shotwell]

> From: Arnout Vandecappelle <arnout at mind.be>
> To: Thomas De Schampheleire <patrickdepinguin at gmail.com>, "Yann E. 
> MORIN" <yann.morin.1998 at free.fr>
> Cc: buildroot <buildroot at busybox.net>
> Date: 01/09/2014 01:46 AM
> Subject: Re: [Buildroot] [RFC] python: select vs depends on
> Sent by: buildroot-bounces at busybox.net
> 
> On 25/12/13 19:42, Thomas De Schampheleire wrote:
> > Hi Yann,
> >
> > On Tue, Dec 24, 2013 at 6:28 PM, Yann E. MORIN <yann.morin.
> 1998 at free.fr> wrote:
> >> On 2013-12-24 18:14 +0100, Thomas De Schampheleire spake thusly:
> >>> Currently, we have a dual strategy with respect to packages that 
have
> >>> optional Python support: alsa-lib uses 'depends on python' for its
> >>> 'python support' option, while ola uses 'select python' for its
> >>> 'python bindings'.
> >> [--SNIP--]
> >>> - python modules (typically named python-foo): here the current
> >>> strategy is to use 'depends on', and this is followed by all such
> >>> packages. For me, this is perfectly sane, and is (IMO) not open for
> >>> discussion.
> >>> Note: in fact, all these modules are in one 'if python' block in
> >>> package/Config.in, and I have prepared a patch to remove the 
redundant
> >>> 'depends on'.
> >>>
> >>> - for 'normal' packages that need python for there normal behavior, 
we
> >>> typically use 'select python'. In this case, the user may not be 
aware
> >>> of the python dependency, and requiring him/her to first enable 
python
> >>> is not logical. I think this reasoning is sane too.
> >>>
> >>> - for 'normal' packages that do not require python, but have 
optional
> >>> python support (as is the case for ola and alsa-lib), I have no 
strong
> >>> preference. Whichever is preferred by the community is ok with me, 
as
> >>> long as we keep one guideline for this case.
> >>
> >> Or what about just removing the 'depends on' or 'select' for packages
> >> sub-options, and just add the dependencies and options in the .mk 
files,
> >> such as:
> >>
> >> ---8<--- alsa-lib.mk ---8<---
> >> ifeq ($(or $(BR2_PACKAGE_PYTHON),$(BR2_PACKAGE_PYTHON3)),y)
> >> ALSA_LIB_CONF_OPT += \
> >>          --with-pythonlibs=-lpython$(PYTHON_VERSION_MAJOR) \
> >>          --with-pythonincludes=$(STAGING_DIR)/usr/include/python$
> (PYTHON_VERSION_MAJOR)
> >> 
ALSA_LIB_CFLAGS+=-I$(STAGING_DIR)/usr/include/python$(PYTHON_VERSION_MAJOR)
> >> ALSA_LIB_DEPENDENCIES = python
> >> else
> >> ALSA_LIB_CONF_OPT += --disable-python
> >> endif
> >> ---8<--- alsa-lib.mk ---8<---
> >>
> >> And so on for other packages...
> >>
> >> We already ave this behaviour in other packages:
> >>    - bind adds features if openssl or libxml2 are selected
> >>    - libvncserver, with libgcrypt, libjpeg, or openssl
> >>    - libpcap, with libusb or libnl
> >>    - and so on. countless times...
> >
> > To me that sounds fine. So for optional support of other packages, we
> > automatically enable it when the dependency is present, from the .mk
> > file, and the Config.in does not contain an explicit option.
> >
> > Is this accepted by other contributors as well?
> 
>   I agree with the principle that scripting language bindings are 
enabled 
> automatically when the scripting language is selected.
> 
>   There could be exceptions when the bindings add a lot of bloat, like 
> e.g. Riverbank's python bindings of Qt4 (but these are anyway a separate 

> package).

For what it's worth, I added in menuconfig options to all of the SELinux 
packages to specifically enable the Python bindings.  When that option is 
enabled, Python is selected.  Doing it this was way chosen after several 
conversations with Thomas P. about the issue.

Thanks,
Clayton

Clayton Shotwell
Software Engineer
clshotwe at rockwellcollins.com
www.rockwellcollins.com