[Buildroot] [PATCH 0 of 9] Python depends on/select cleanup

[Buildroot] [PATCH 0 of 9] Python depends on/select cleanup

[Thomas De Schampheleire]

Hi,

This patch series cleans up the packages depending on Python with the
strategy discussed earlier on the mailing list. The new strategy is
clarified in the manual.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 docs/manual/adding-packages-dependencies.txt |  281 +++++++++++++++++++++++
 docs/manual/adding-packages-directory.txt    |  236 +-------------------
 package/alsa-lib/Config.in                   |    9 -
 package/alsa-lib/alsa-lib.mk                 |    2 +-
 package/libdnet/Config.in                    |   13 -
 package/libdnet/libdnet.mk                   |    2 +-
 package/ola/Config.in                        |   15 +-
 package/ola/ola.mk                           |    2 +-
 package/python-posix-ipc/Config.in           |    1 +
 package/python-pyasn/Config.in               |    1 +
 package/python-pysnmp-apps/Config.in         |    1 +
 package/python-pysnmp-mibs/Config.in         |    1 +
 package/python-pysnmp/Config.in              |    1 +
 package/spice/Config.in                      |   11 +-
 package/supervisor/Config.in                 |    9 +-
 15 files changed, 307 insertions(+), 278 deletions(-)

[Buildroot] [PATCH 1 of 9] manual: split information about Config.in dependencies to a separate file

[Thomas De Schampheleire]

The information about expressing dependencies in Config.in files is becoming
larger, and is more easily maintained from a separate file than from the
current file 'adding-packages-directory.txt'.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 docs/manual/adding-packages-dependencies.txt |  235 ++++++++++++++++++++++
 docs/manual/adding-packages-directory.txt    |  236 +----------------------
 2 files changed, 236 insertions(+), 235 deletions(-)

diff --git a/docs/manual/adding-packages-dependencies.txt b/docs/manual/adding-packages-dependencies.txt
new file mode 100644
--- /dev/null
+++ b/docs/manual/adding-packages-dependencies.txt
@@ -0,0 +1,235 @@
+[[depends-on-vs-select]]
+Choosing +depends on+ or +select+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The +Config.in+ file of your package must also ensure that
+dependencies are enabled. Typically, Buildroot uses the following
+rules:
+
+* Use a +select+ type of dependency for dependencies on
+  libraries. These dependencies are generally not obvious and it
+  therefore make sense to have the kconfig system ensure that the
+  dependencies are selected. For example, the _libgtk2_ package uses
+  +select BR2_PACKAGE_LIBGLIB2+ to make sure this library is also
+  enabled.
+  The +select+ keyword expresses the dependency with a backward
+  semantic.
+
+* Use a +depends on+ type of dependency when the user really needs to
+  be aware of the dependency. Typically, Buildroot uses this type of
+  dependency for dependencies on target architecture, MMU support and
+  toolchain options (see xref:dependencies-target-toolchain-options[]),
+  or for dependencies on "big" things, such as the X.org system.
+  The +depends on+ keyword expresses the dependency with a forward
+  semantic.
+
+.Note
+The current problem with the _kconfig_ language is that these two
+dependency semantics are not internally linked. Therefore, it may be
+possible to select a package, whom one of its dependencies/requirement
+is not met.
+
+An example illustrates both the usage of +select+ and +depends on+.
+
+--------------------------
+config BR2_PACKAGE_ACL
+        bool "acl"
+        select BR2_PACKAGE_ATTR
+        depends on BR2_LARGEFILE
+        help
+          POSIX Access Control Lists, which are used to define more
+          fine-grained discretionary access rights for files and
+          directories.
+          This package also provides libacl.
+
+          http://savannah.nongnu.org/projects/acl
+
+comment "acl needs a toolchain w/ largefile"
+        depends on !BR2_LARGEFILE
+--------------------------
+
+
+Note that these two dependency types are only transitive with the
+dependencies of the same kind.
+
+This means, in the following example:
+
+--------------------------
+config BR2_PACKAGE_A
+        bool "Package A"
+
+config BR2_PACKAGE_B
+        bool "Package B"
+        depends on BR2_PACKAGE_A
+
+config BR2_PACKAGE_C
+        bool "Package C"
+        depends on BR2_PACKAGE_B
+
+config BR2_PACKAGE_D
+        bool "Package D"
+        select BR2_PACKAGE_B
+
+config BR2_PACKAGE_E
+        bool "Package E"
+        select BR2_PACKAGE_D
+--------------------------
+
+* Selecting +Package C+ will be visible if +Package B+ has been
+  selected, which in turn is only visible if +Package A+ has been
+  selected.
+
+* Selecting +Package E+ will select +Package D+, which will select
+  +Package B+, it will not check for the dependencies of +Package B+,
+  so it will not select +Package A+.
+
+* Since +Package B+ is selected but +Package A+ is not, this violates
+  the dependency of +Package B+ on +Package A+.  Therefore, in such a
+  situation, the transitive dependency has to be added explicitly:
+
+--------------------------
+config BR2_PACKAGE_D
+	bool "Package D"
+	select BR2_PACKAGE_B
+	depends on BR2_PACKAGE_A
+
+config BR2_PACKAGE_E
+	bool "Package E"
+	select BR2_PACKAGE_D
+	depends on BR2_PACKAGE_A
+--------------------------
+
+Overall, for package library dependencies, +select+ should be
+preferred.
+
+Note that such dependencies will ensure that the dependency option
+is also enabled, but not necessarily built before your package. To do
+so, the dependency also needs to be expressed in the +.mk+ file of the
+package.
+
+Further formatting details: see xref:writing-rules-config-in[the
+coding style].
+
+[[dependencies-target-toolchain-options]]
+Dependencies on target and toolchain options
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Many packages depend on certain options of the toolchain: the choice of
+C library, C++ support, largefile support, thread support, RPC support,
+IPv6 support, wchar support, or dynamic library support. Some packages
+can only be built on certain target architectures, or if an MMU is
+available in the processor.
+
+These dependencies have to be expressed with the appropriate 'depends
+on' statements in the Config.in file. Additionally, for dependencies on
+toolchain options, a +comment+ should be displayed when the option is
+not enabled, so that the user knows why the package is not available.
+Dependencies on target architecture or MMU support should not be
+made visible in a comment: since it is unlikely that the user can
+freely choose another target, it makes little sense to show these
+dependencies explicitly.
+
+The +comment+ should only be visible if the +config+ option itself would
+be visible when the toolchain option dependencies are met. This means
+that all other dependencies of the package (including dependencies on
+target architecture and MMU support) have to be repeated on the
++comment+ definition. To keep it clear, the +depends on+ statement for
+these non-toolchain option should be kept separate from the +depends on+
+statement for the toolchain options.
+If there is a dependency on a config option in that same file (typically
+the main package) it is preferable to have a global +if ... endif+
+construct rather than repeating the +depends on+ statement on the
+comment and other config options.
+
+The general format of a dependency +comment+ for package foo is:
+--------------------------
+foo needs a toolchain w/ featA, featB, featC
+--------------------------
+
+for example:
+--------------------------
+aircrack-ng needs a toolchain w/ largefile, threads
+--------------------------
+
+Note that this text is kept brief on purpose, so that it will fit on a
+80-character terminal.
+
+The rest of this section enumerates the different target and toolchain
+options, the corresponding config symbols to depend on, and the text to
+use in the comment.
+
+* Target architecture
+** Dependency symbol: +BR2_powerpc+, +BR2_mips+, ... (see +arch/Config.in+)
+** Comment string: no comment to be added
+
+* MMU support
+** Dependency symbol: +BR2_USE_MMU+
+** Comment string: no comment to be added
+
+* C library
+** Dependency symbol: +BR2_TOOLCHAIN_USES_GLIBC+,
++BR2_TOOLCHAIN_USES_UCLIBC+
+** Comment string: for the C library, a slightly different comment text
+   is used: +foo needs an (e)glibc toolchain+, or `foo needs an (e)glibc
+   toolchain w/ C++ support`
+
+* C++ support
+** Dependency symbol: +BR2_INSTALL_LIBSTDCPP+
+** Comment string: `C++`
+
+* largefile support
+** Dependency symbol: +BR2_LARGEFILE+
+** Comment string: +largefile+
+
+* thread support
+** Dependency symbol: +BR2_TOOLCHAIN_HAS_THREADS+
+** Comment string: +threads+
+
+* RPC support
+** Dependency symbol: +BR2_TOOLCHAIN_HAS_NATIVE_RPC+
+** Comment string: +RPC+
+
+* IPv6 support
+** Dependency symbol: +BR2_INET_IPV6+
+** Comment string: +IPv6+ (lowercase v)
+
+* wchar support
+** Dependency symbol: +BR2_USE_WCHAR+
+** Comment string: +wchar+
+
+* dynamic library
+** Dependency symbol: +!BR2_PREFER_STATIC_LIB+
+** Comment string: +dynamic library+
+
+Dependencies on a Linux kernel built by buildroot
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Some packages need a Linux kernel to be built by buildroot. These are
+typically kernel modules or firmware. A comment should be added in the
+Config.in file to express this dependency, similar to dependencies on
+toolchain options. The general format is:
+
+--------------------------
+foo needs a Linux kernel to be built
+--------------------------
+
+If there is a dependency on both toolchain options and the Linux
+kernel, use this format:
+--------------------------
+foo needs a toolchain w/ featA, featB, featC and a Linux kernel to be built
+--------------------------
+
+Dependencies on udev /dev management
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+If a package needs udev /dev management, it should depend on symbol
++BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV+, and the following comment
+should be added:
+
+--------------------------
+foo needs udev /dev management
+--------------------------
+
+If there is a dependency on both toolchain options and udev /dev
+management, use this format:
+
+--------------------------
+foo needs udev /dev management and a toolchain w/ featA, featB, featC
+--------------------------
diff --git a/docs/manual/adding-packages-directory.txt b/docs/manual/adding-packages-directory.txt
--- a/docs/manual/adding-packages-directory.txt
+++ b/docs/manual/adding-packages-directory.txt
@@ -51,241 +51,7 @@ supposed to contain anything but the 'ba
 source "package/libfoo/Config.in"
 --------------------------
 
-[[depends-on-vs-select]]
-Choosing +depends on+ or +select+
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The +Config.in+ file of your package must also ensure that
-dependencies are enabled. Typically, Buildroot uses the following
-rules:
-
-* Use a +select+ type of dependency for dependencies on
-  libraries. These dependencies are generally not obvious and it
-  therefore make sense to have the kconfig system ensure that the
-  dependencies are selected. For example, the _libgtk2_ package uses
-  +select BR2_PACKAGE_LIBGLIB2+ to make sure this library is also
-  enabled.
-  The +select+ keyword expresses the dependency with a backward
-  semantic.
-
-* Use a +depends on+ type of dependency when the user really needs to
-  be aware of the dependency. Typically, Buildroot uses this type of
-  dependency for dependencies on target architecture, MMU support and
-  toolchain options (see xref:dependencies-target-toolchain-options[]),
-  or for dependencies on "big" things, such as the X.org system.
-  The +depends on+ keyword expresses the dependency with a forward
-  semantic.
-
-.Note
-The current problem with the _kconfig_ language is that these two
-dependency semantics are not internally linked. Therefore, it may be
-possible to select a package, whom one of its dependencies/requirement
-is not met.
-
-An example illustrates both the usage of +select+ and +depends on+.
-
---------------------------
-config BR2_PACKAGE_ACL
-        bool "acl"
-        select BR2_PACKAGE_ATTR
-        depends on BR2_LARGEFILE
-        help
-          POSIX Access Control Lists, which are used to define more
-          fine-grained discretionary access rights for files and
-          directories.
-          This package also provides libacl.
-
-          http://savannah.nongnu.org/projects/acl
-
-comment "acl needs a toolchain w/ largefile"
-        depends on !BR2_LARGEFILE
---------------------------
-
-
-Note that these two dependency types are only transitive with the
-dependencies of the same kind.
-
-This means, in the following example:
-
---------------------------
-config BR2_PACKAGE_A
-        bool "Package A"
-
-config BR2_PACKAGE_B
-        bool "Package B"
-        depends on BR2_PACKAGE_A
-
-config BR2_PACKAGE_C
-        bool "Package C"
-        depends on BR2_PACKAGE_B
-
-config BR2_PACKAGE_D
-        bool "Package D"
-        select BR2_PACKAGE_B
-
-config BR2_PACKAGE_E
-        bool "Package E"
-        select BR2_PACKAGE_D
---------------------------
-
-* Selecting +Package C+ will be visible if +Package B+ has been
-  selected, which in turn is only visible if +Package A+ has been
-  selected.
-
-* Selecting +Package E+ will select +Package D+, which will select
-  +Package B+, it will not check for the dependencies of +Package B+,
-  so it will not select +Package A+.
-
-* Since +Package B+ is selected but +Package A+ is not, this violates
-  the dependency of +Package B+ on +Package A+.  Therefore, in such a
-  situation, the transitive dependency has to be added explicitly:
-
---------------------------
-config BR2_PACKAGE_D
-	bool "Package D"
-	select BR2_PACKAGE_B
-	depends on BR2_PACKAGE_A
-
-config BR2_PACKAGE_E
-	bool "Package E"
-	select BR2_PACKAGE_D
-	depends on BR2_PACKAGE_A
---------------------------
-
-Overall, for package library dependencies, +select+ should be
-preferred.
-
-Note that such dependencies will ensure that the dependency option
-is also enabled, but not necessarily built before your package. To do
-so, the dependency also needs to be expressed in the +.mk+ file of the
-package.
-
-Further formatting details: see xref:writing-rules-config-in[the
-coding style].
-
-[[dependencies-target-toolchain-options]]
-Dependencies on target and toolchain options
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Many packages depend on certain options of the toolchain: the choice of
-C library, C++ support, largefile support, thread support, RPC support,
-IPv6 support, wchar support, or dynamic library support. Some packages
-can only be built on certain target architectures, or if an MMU is
-available in the processor.
-
-These dependencies have to be expressed with the appropriate 'depends
-on' statements in the Config.in file. Additionally, for dependencies on
-toolchain options, a +comment+ should be displayed when the option is
-not enabled, so that the user knows why the package is not available.
-Dependencies on target architecture or MMU support should not be
-made visible in a comment: since it is unlikely that the user can
-freely choose another target, it makes little sense to show these
-dependencies explicitly.
-
-The +comment+ should only be visible if the +config+ option itself would
-be visible when the toolchain option dependencies are met. This means
-that all other dependencies of the package (including dependencies on
-target architecture and MMU support) have to be repeated on the
-+comment+ definition. To keep it clear, the +depends on+ statement for
-these non-toolchain option should be kept separate from the +depends on+
-statement for the toolchain options.
-If there is a dependency on a config option in that same file (typically
-the main package) it is preferable to have a global +if ... endif+
-construct rather than repeating the +depends on+ statement on the
-comment and other config options.
-
-The general format of a dependency +comment+ for package foo is:
---------------------------
-foo needs a toolchain w/ featA, featB, featC
---------------------------
-
-for example:
---------------------------
-aircrack-ng needs a toolchain w/ largefile, threads
---------------------------
-
-Note that this text is kept brief on purpose, so that it will fit on a
-80-character terminal.
-
-The rest of this section enumerates the different target and toolchain
-options, the corresponding config symbols to depend on, and the text to
-use in the comment.
-
-* Target architecture
-** Dependency symbol: +BR2_powerpc+, +BR2_mips+, ... (see +arch/Config.in+)
-** Comment string: no comment to be added
-
-* MMU support
-** Dependency symbol: +BR2_USE_MMU+
-** Comment string: no comment to be added
-
-* C library
-** Dependency symbol: +BR2_TOOLCHAIN_USES_GLIBC+,
-+BR2_TOOLCHAIN_USES_UCLIBC+
-** Comment string: for the C library, a slightly different comment text
-   is used: +foo needs an (e)glibc toolchain+, or `foo needs an (e)glibc
-   toolchain w/ C++ support`
-
-* C++ support
-** Dependency symbol: +BR2_INSTALL_LIBSTDCPP+
-** Comment string: `C++`
-
-* largefile support
-** Dependency symbol: +BR2_LARGEFILE+
-** Comment string: +largefile+
-
-* thread support
-** Dependency symbol: +BR2_TOOLCHAIN_HAS_THREADS+
-** Comment string: +threads+
-
-* RPC support
-** Dependency symbol: +BR2_TOOLCHAIN_HAS_NATIVE_RPC+
-** Comment string: +RPC+
-
-* IPv6 support
-** Dependency symbol: +BR2_INET_IPV6+
-** Comment string: +IPv6+ (lowercase v)
-
-* wchar support
-** Dependency symbol: +BR2_USE_WCHAR+
-** Comment string: +wchar+
-
-* dynamic library
-** Dependency symbol: +!BR2_PREFER_STATIC_LIB+
-** Comment string: +dynamic library+
-
-Dependencies on a Linux kernel built by buildroot
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Some packages need a Linux kernel to be built by buildroot. These are
-typically kernel modules or firmware. A comment should be added in the
-Config.in file to express this dependency, similar to dependencies on
-toolchain options. The general format is:
-
---------------------------
-foo needs a Linux kernel to be built
---------------------------
-
-If there is a dependency on both toolchain options and the Linux
-kernel, use this format:
---------------------------
-foo needs a toolchain w/ featA, featB, featC and a Linux kernel to be built
---------------------------
-
-Dependencies on udev /dev management
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-If a package needs udev /dev management, it should depend on symbol
-+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV+, and the following comment
-should be added:
-
---------------------------
-foo needs udev /dev management
---------------------------
-
-If there is a dependency on both toolchain options and udev /dev
-management, use this format:
-
---------------------------
-foo needs udev /dev management and a toolchain w/ featA, featB, featC
---------------------------
+include::adding-packages-dependencies.txt[]
 
 The +.mk+ file
 ~~~~~~~~~~~~~~

[Buildroot] [PATCH 2 of 9] manual: split information about Config.in dependencies to a separate section

[Thomas De Schampheleire]

As the information about adding dependencies in Config.in files is
important and involves a number of rules, make sure it is mentioned in the
table of contents by creating a section for it.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 docs/manual/adding-packages-dependencies.txt |  3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/docs/manual/adding-packages-dependencies.txt b/docs/manual/adding-packages-dependencies.txt
--- a/docs/manual/adding-packages-dependencies.txt
+++ b/docs/manual/adding-packages-dependencies.txt
@@ -1,3 +1,6 @@
+Expressing dependencies in +Config.in+ files
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 [[depends-on-vs-select]]
 Choosing +depends on+ or +select+
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Buildroot] [PATCH 3 of 9] manual: explain how to express Python dependencies

[Thomas De Schampheleire]

As discussed on the mailing list [1] [2], there are basically three cases in
which a package may need to depend on the Python interpreter. This patch
clarifies what to add in Config.in in these three cases.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

[1] http://lists.busybox.net/pipermail/buildroot/2013-December/085324.html
[2] http://lists.busybox.net/pipermail/buildroot/2014-January/086396.html

---
 docs/manual/adding-packages-dependencies.txt |  43 ++++++++++++++++++++++++
 1 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/docs/manual/adding-packages-dependencies.txt b/docs/manual/adding-packages-dependencies.txt
--- a/docs/manual/adding-packages-dependencies.txt
+++ b/docs/manual/adding-packages-dependencies.txt
@@ -236,3 +236,46 @@ management, use this format:
 --------------------------
 foo needs udev /dev management and a toolchain w/ featA, featB, featC
 --------------------------
+
+Dependencies on the Python interpreter
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+How to depend on the Python interpreter depends on the type of package.
+
+If the package is _a Python module_, it should use +depends on
+BR2_PACKAGE_PYTHON+. There shouldn't be any comment making this
+dependency explicit to the user, as it should be obvious that Python
+modules require Python to be enabled.
+
+If the package is _a regular (non-Python) package that requires Python_
+to function properly, it should use +select BR2_PACKAGE_PYTHON+. The
+reasoning here is that it is not user-friendly to require the user to
+enable Python prior to being able to enable this package, since the
+Python dependency is not obvious. As in the previous case, there
+shouldn't be any comment mentioning this Python dependency. However,
+the regular rules for propagating package dependencies when selecting
+a package still apply: you'll need to add +depends on+ statements for
+Python's dependencies, and you'll need to add an appropriate comment,
+as explained in xref:dependencies-target-toolchain-options[].
+
+If the package is _a regular (non-Python) package that has an optional
+Python dependency_ (for example because it provides optional Python
+bindings), this should be handled transparently in the +.mk+ file of
+the package. If Python is enabled, the optional support should be
+enabled as well. If Python is disabled, then so should the optional
+support. In this case, there is nothing added in the +Config.in+
+file. A typical construct in the +.mk+ file is:
+--------------------------
+  ifeq ($(BR2_PACKAGE_PYTHON),y)
+  LIBFOO_CONF_OPT += --with-python-support
+  LIBFOO_DEPENDENCIES += python
+  else
+  LIBFOO_CONF_OPT += --without-python-support
+  endif
+--------------------------
+
+Exceptions to this last rule can be made if the optional support has a
+large impact that is not acceptable for all users, unless explicitly
+requested. In this case, add an explicit config option to the
++Config.in+ file to enable the optional Python support. This option
+should use +depends on BR2_PACKAGE_PYTHON+. Again, there shouldn't be
+any comment mentioning this dependency.

[Buildroot] [PATCH 4 of 9] python modules: add missing depends on Config.in comments

[Thomas De Schampheleire]

Config.in comments about toolchain dependencies should only be visible when
the option they refer to would be visible (had the dependencies been met).
While python modules are currently already only visible when python is
enabled, thanks to a 'depends on BR2_PACKAGE_PYTHON' in package/Config.in,
we explicitly keep the 'depends on' statement for the packages themselves,
in anticipation of the introduction of Python 3 support.
Hence, the python dependency should be replicated on the comments, just as
for other packages.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/python-posix-ipc/Config.in   |  1 +
 package/python-pyasn/Config.in       |  1 +
 package/python-pysnmp-apps/Config.in |  1 +
 package/python-pysnmp-mibs/Config.in |  1 +
 package/python-pysnmp/Config.in      |  1 +
 5 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/package/python-posix-ipc/Config.in b/package/python-posix-ipc/Config.in
--- a/package/python-posix-ipc/Config.in
+++ b/package/python-posix-ipc/Config.in
@@ -11,4 +11,5 @@ config BR2_PACKAGE_PYTHON_POSIX_IPC
 	  http://semanchuk.com/philip/posix_ipc/
 
 comment "python-posix-ipc needs a toolchain w/ threads"
+	depends on BR2_PACKAGE_PYTHON
 	depends on !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/python-pyasn/Config.in b/package/python-pyasn/Config.in
--- a/package/python-pyasn/Config.in
+++ b/package/python-pyasn/Config.in
@@ -10,4 +10,5 @@ config BR2_PACKAGE_PYTHON_PYASN
 	  https://code.google.com/p/pyasn/
 
 comment "python-pyasn needs a toolchain w/ C++"
+	depends on BR2_PACKAGE_PYTHON
 	depends on !BR2_INSTALL_LIBSTDCPP
diff --git a/package/python-pysnmp-apps/Config.in b/package/python-pysnmp-apps/Config.in
--- a/package/python-pysnmp-apps/Config.in
+++ b/package/python-pysnmp-apps/Config.in
@@ -10,4 +10,5 @@ config BR2_PACKAGE_PYTHON_PYSNMP_APPS
 	  http://pysnmp.sf.net
 
 comment "python-pysnmp-apps needs a toolchain w/ C++"
+	depends on BR2_PACKAGE_PYTHON
 	depends on !BR2_INSTALL_LIBSTDCPP
diff --git a/package/python-pysnmp-mibs/Config.in b/package/python-pysnmp-mibs/Config.in
--- a/package/python-pysnmp-mibs/Config.in
+++ b/package/python-pysnmp-mibs/Config.in
@@ -10,4 +10,5 @@ config BR2_PACKAGE_PYTHON_PYSNMP_MIBS
 	  http://pysnmp.sf.net
 
 comment "python-pysnmp-libs needs a toolchain w/ C++"
+	depends on BR2_PACKAGE_PYTHON
 	depends on !BR2_INSTALL_LIBSTDCPP
diff --git a/package/python-pysnmp/Config.in b/package/python-pysnmp/Config.in
--- a/package/python-pysnmp/Config.in
+++ b/package/python-pysnmp/Config.in
@@ -11,4 +11,5 @@ config BR2_PACKAGE_PYTHON_PYSNMP
 	  http://pysnmp.sf.net
 
 comment "python-pysnmp needs a toolchain w/ C++"
+	depends on BR2_PACKAGE_PYTHON
 	depends on !BR2_INSTALL_LIBSTDCPP

[Buildroot] [PATCH 5 of 9] alsa-lib: automatically enable python bindings if python is enabled

[Thomas De Schampheleire]

For packages with optional python bindings, these bindings can be enabled
automatically when python is enabled. There is no need for explicit
configuration options, unless there is a very good reason to do so.

No legacy option was enabled as there is no impact on users that had the
original explicit symbol enabled.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/alsa-lib/Config.in   |  9 ---------
 package/alsa-lib/alsa-lib.mk |  2 +-
 2 files changed, 1 insertions(+), 10 deletions(-)

diff --git a/package/alsa-lib/Config.in b/package/alsa-lib/Config.in
--- a/package/alsa-lib/Config.in
+++ b/package/alsa-lib/Config.in
@@ -20,15 +20,6 @@ comment "alsa-lib needs a toolchain w/ t
 
 if BR2_PACKAGE_ALSA_LIB
 
-config BR2_PACKAGE_ALSA_LIB_PYTHON
-	bool "Python support for alsa-lib"
-	depends on BR2_PACKAGE_PYTHON
-	help
-	  Add python support for alsa-lib.
-	  Python will be built and libpython will be installed
-	  in the target directory
-	  http://www.alsa-project.org/
-
 menu "ALSA lib selection"
 
 config BR2_PACKAGE_ALSA_LIB_DEVDIR
diff --git a/package/alsa-lib/alsa-lib.mk b/package/alsa-lib/alsa-lib.mk
--- a/package/alsa-lib/alsa-lib.mk
+++ b/package/alsa-lib/alsa-lib.mk
@@ -57,7 +57,7 @@ ifeq ($(BR2_avr32),y)
 ALSA_LIB_CFLAGS += -DAVR32_INLINE_BUG
 endif
 
-ifeq ($(BR2_PACKAGE_ALSA_LIB_PYTHON),y)
+ifeq ($(BR2_PACKAGE_PYTHON),y)
 ALSA_LIB_CONF_OPT += \
 	--with-pythonlibs=-lpython$(PYTHON_VERSION_MAJOR) \
 	--with-pythonincludes=$(STAGING_DIR)/usr/include/python$(PYTHON_VERSION_MAJOR)

[Buildroot] [PATCH 6 of 9] libdnet: automatically enable python bindings if python is enabled

[Thomas De Schampheleire]

For packages with optional python bindings, these bindings can be enabled
automatically when python is enabled. There is no need for explicit
configuration options, unless there is a very good reason to do so.

No legacy option was enabled as there is no impact on users that had the
original explicit symbol enabled.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/libdnet/Config.in  |  13 -------------
 package/libdnet/libdnet.mk |   2 +-
 2 files changed, 1 insertions(+), 14 deletions(-)

diff --git a/package/libdnet/Config.in b/package/libdnet/Config.in
--- a/package/libdnet/Config.in
+++ b/package/libdnet/Config.in
@@ -4,16 +4,3 @@ config BR2_PACKAGE_LIBDNET
 	  libdnet - simplified interface to low-level networking routines.
 
 	  http://libdnet.sourceforge.net/
-
-if BR2_PACKAGE_LIBDNET
-
-config BR2_PACKAGE_LIBDNET_PYTHON
-	bool "libdnet python module"
-	depends on BR2_PACKAGE_PYTHON
-	help
-	  dnet module for python
-
-comment "dnet module for python requires python package"
-	depends on !BR2_PACKAGE_PYTHON
-
-endif
diff --git a/package/libdnet/libdnet.mk b/package/libdnet/libdnet.mk
--- a/package/libdnet/libdnet.mk
+++ b/package/libdnet/libdnet.mk
@@ -14,7 +14,7 @@ LIBDNET_CONF_OPT = \
 	--with-gnu-ld \
 	--with-check=no
 
-ifneq ($(BR2_PACKAGE_LIBDNET_PYTHON),)
+ifeq ($(BR2_PACKAGE_PYTHON),y)
 LIBDNET_DEPENDENCIES = python
 LIBDNET_CONF_OPT += --with-python
 LIBDNET_MAKE_OPT = PYINCDIR=$(STAGING_DIR)/usr/include/python$(PYTHON_VERSION_MAJOR) PYLIBDIR=$(STAGING_DIR)/usr/lib

[Buildroot] [PATCH 7 of 9] ola: automatically enable python bindings if python is enabled

[Thomas De Schampheleire]

For packages with optional python bindings, these bindings can be enabled
automatically when python is enabled. There is no need for explicit
configuration options, unless there is a very good reason to do so.

No legacy option was enabled as there is no impact on users that had the
original explicit symbol enabled.

Ola itself has optional python bindings, these are now automatically enabled
if python is enabled. The rdm tests are treated as a package that requires
python, and thus _selects_ python rather than depending on it.

This commit additionally adds a missing dependency on wchar, needed for
python.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/ola/Config.in |  15 ++++++---------
 package/ola/ola.mk    |   2 +-
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/package/ola/Config.in b/package/ola/Config.in
--- a/package/ola/Config.in
+++ b/package/ola/Config.in
@@ -27,14 +27,6 @@ config BR2_PACKAGE_OLA_WEB
 	help
 	  Build OLA with browser interface.
 
-config BR2_PACKAGE_OLA_PYTHON_BINDINGS
-	bool "python bindings"
-	select BR2_PACKAGE_PYTHON
-	select BR2_PACKAGE_PYTHON_PROTOBUF
-	depends on BR2_USE_MMU
-	help
-	  Build OLA with support for the Python language.
-
 config BR2_PACKAGE_OLA_SLP
 	bool "slp tools"
 	help
@@ -52,11 +44,16 @@ config BR2_PACKAGE_OLA_EXAMPLES
 
 config BR2_PACKAGE_OLA_RDM_TESTS
 	bool "rdm tests"
-	select BR2_PACKAGE_OLA_PYTHON_BINDINGS
+	select BR2_PACKAGE_PYTHON
 	depends on BR2_USE_MMU
+	depends on BR2_USE_WCHAR # python
 	help
 	  Build OLA RDM tests.
 
+comment "rdm tests need a toolchain w/ wchar"
+	depends on BR2_USE_MMU
+	depends on !BR2_USE_WCHAR
+
 endmenu
 
 menu "plugin selections"
diff --git a/package/ola/ola.mk b/package/ola/ola.mk
--- a/package/ola/ola.mk
+++ b/package/ola/ola.mk
@@ -45,7 +45,7 @@ else
 OLA_CONF_OPT += --disable-slp
 endif
 
-ifeq ($(BR2_PACKAGE_OLA_PYTHON_BINDINGS),y)
+ifeq ($(BR2_PACKAGE_PYTHON),y)
 OLA_CONF_OPT += --enable-python-libs
 OLA_DEPENDENCIES += python python-protobuf
 else

[Buildroot] [PATCH 8 of 9] spice: automatically select python

[Thomas De Schampheleire]

Packages that have a required dependency on python should select python
instead of depending on it, as this is most logical towards the user (which
may not clearly realize the python dependency).

This commit also updates the comments about toolchain options, adding
missing base dependencies (arch) and the extra mmu dependency for python.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/spice/Config.in |  11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/package/spice/Config.in b/package/spice/Config.in
--- a/package/spice/Config.in
+++ b/package/spice/Config.in
@@ -1,15 +1,13 @@
 comment "spice server needs a toolchain w/ wchar, threads"
+	depends on BR2_i386 || BR2_x86_64
+	depends on BR2_USE_MMU
 	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
 
-comment "spice server depends on python (for pyparsing)"
-	depends on BR2_i386 || BR2_x86_64
-	depends on !BR2_PACKAGE_PYTHON
-
 config BR2_PACKAGE_SPICE
 	bool "spice server"
 	depends on BR2_i386 || BR2_x86_64
-	depends on BR2_PACKAGE_PYTHON
-	depends on BR2_USE_WCHAR # libglib2
+	depends on BR2_USE_MMU # python
+	depends on BR2_USE_WCHAR # libglib2, python
 	depends on BR2_TOOLCHAIN_HAS_THREADS # libglib2
 	select BR2_PACKAGE_ALSA_LIB
 	select BR2_PACKAGE_CELT051
@@ -17,6 +15,7 @@ config BR2_PACKAGE_SPICE
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_OPENSSL
 	select BR2_PACKAGE_PIXMAN
+	select BR2_PACKAGE_PYTHON
 	select BR2_PACKAGE_PYTHON_PYPARSING
 	select BR2_PACKAGE_SPICE_PROTOCOL
 	help

[Buildroot] [PATCH 9 of 9] supervisor: automatically select python

[Thomas De Schampheleire]

Packages that have a required dependency on python should select python
instead of depending on it, as this is most logical towards the user (which
may not clearly realize the python dependency).

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/supervisor/Config.in |  9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/package/supervisor/Config.in b/package/supervisor/Config.in
--- a/package/supervisor/Config.in
+++ b/package/supervisor/Config.in
@@ -1,12 +1,15 @@
 config BR2_PACKAGE_SUPERVISOR
 	bool "supervisor"
-	depends on BR2_PACKAGE_PYTHON
+	select BR2_PACKAGE_PYTHON
 	select BR2_PACKAGE_PYTHON_MELD3
+	depends on BR2_USE_MMU # python
+	depends on BR2_USE_WCHAR # python
 	help
 	  A client/server system that allows its users to control a
 	  number of processes on UNIX-like operating systems.
 
 	  http://supervisord.org/
 
-comment "supervisor needs the python interpreter"
-	depends on !BR2_PACKAGE_PYTHON
+comment "supervisor needs a toolchain w/ wchar"
+	depends on BR2_USE_MMU
+	depends on !BR2_USE_WCHAR