Python depends on/select cleanup

new file mode 100644
@@ -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
+--------------------------

242 lines not on this page · raw message

@@ -1,3 +1,6 @@
+Expressing dependencies in +Config.in+ files
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 [[depends-on-vs-select]]
 Choosing +depends on+ or +select+
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

@@ -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.

@@ -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

@@ -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

@@ -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

@@ -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

@@ -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

@@ -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

@@ -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)

@@ -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

@@ -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

@@ -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"

@@ -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

@@ -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

@@ -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