* [Buildroot] [PATCH 1 of 9] manual: split information about Config.in dependencies to a separate file
2014-02-02 12:11 [Buildroot] [PATCH 0 of 9] Python depends on/select cleanup Thomas De Schampheleire
@ 2014-02-02 12:11 ` Thomas De Schampheleire
2014-02-02 12:11 ` [Buildroot] [PATCH 2 of 9] manual: split information about Config.in dependencies to a separate section Thomas De Schampheleire
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Thomas De Schampheleire @ 2014-02-02 12:11 UTC (permalink / raw)
To: buildroot
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
~~~~~~~~~~~~~~
^ permalink raw reply [flat|nested] 10+ messages in thread* [Buildroot] [PATCH 2 of 9] manual: split information about Config.in dependencies to a separate section
2014-02-02 12:11 [Buildroot] [PATCH 0 of 9] Python depends on/select cleanup Thomas De Schampheleire
2014-02-02 12:11 ` [Buildroot] [PATCH 1 of 9] manual: split information about Config.in dependencies to a separate file Thomas De Schampheleire
@ 2014-02-02 12:11 ` Thomas De Schampheleire
2014-02-02 12:11 ` [Buildroot] [PATCH 3 of 9] manual: explain how to express Python dependencies Thomas De Schampheleire
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Thomas De Schampheleire @ 2014-02-02 12:11 UTC (permalink / raw)
To: buildroot
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+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^ permalink raw reply [flat|nested] 10+ messages in thread* [Buildroot] [PATCH 3 of 9] manual: explain how to express Python dependencies
2014-02-02 12:11 [Buildroot] [PATCH 0 of 9] Python depends on/select cleanup Thomas De Schampheleire
2014-02-02 12:11 ` [Buildroot] [PATCH 1 of 9] manual: split information about Config.in dependencies to a separate file Thomas De Schampheleire
2014-02-02 12:11 ` [Buildroot] [PATCH 2 of 9] manual: split information about Config.in dependencies to a separate section Thomas De Schampheleire
@ 2014-02-02 12:11 ` Thomas De Schampheleire
2014-02-02 12:11 ` [Buildroot] [PATCH 4 of 9] python modules: add missing depends on Config.in comments Thomas De Schampheleire
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Thomas De Schampheleire @ 2014-02-02 12:11 UTC (permalink / raw)
To: buildroot
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Buildroot] [PATCH 4 of 9] python modules: add missing depends on Config.in comments
2014-02-02 12:11 [Buildroot] [PATCH 0 of 9] Python depends on/select cleanup Thomas De Schampheleire
` (2 preceding siblings ...)
2014-02-02 12:11 ` [Buildroot] [PATCH 3 of 9] manual: explain how to express Python dependencies Thomas De Schampheleire
@ 2014-02-02 12:11 ` Thomas De Schampheleire
2014-02-02 12:11 ` [Buildroot] [PATCH 5 of 9] alsa-lib: automatically enable python bindings if python is enabled Thomas De Schampheleire
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Thomas De Schampheleire @ 2014-02-02 12:11 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Buildroot] [PATCH 5 of 9] alsa-lib: automatically enable python bindings if python is enabled
2014-02-02 12:11 [Buildroot] [PATCH 0 of 9] Python depends on/select cleanup Thomas De Schampheleire
` (3 preceding siblings ...)
2014-02-02 12:11 ` [Buildroot] [PATCH 4 of 9] python modules: add missing depends on Config.in comments Thomas De Schampheleire
@ 2014-02-02 12:11 ` Thomas De Schampheleire
2014-02-02 12:11 ` [Buildroot] [PATCH 6 of 9] libdnet: " Thomas De Schampheleire
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Thomas De Schampheleire @ 2014-02-02 12:11 UTC (permalink / raw)
To: buildroot
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)
^ permalink raw reply [flat|nested] 10+ messages in thread* [Buildroot] [PATCH 6 of 9] libdnet: automatically enable python bindings if python is enabled
2014-02-02 12:11 [Buildroot] [PATCH 0 of 9] Python depends on/select cleanup Thomas De Schampheleire
` (4 preceding siblings ...)
2014-02-02 12:11 ` [Buildroot] [PATCH 5 of 9] alsa-lib: automatically enable python bindings if python is enabled Thomas De Schampheleire
@ 2014-02-02 12:11 ` Thomas De Schampheleire
2014-02-02 12:11 ` [Buildroot] [PATCH 7 of 9] ola: " Thomas De Schampheleire
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Thomas De Schampheleire @ 2014-02-02 12:11 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Buildroot] [PATCH 7 of 9] ola: automatically enable python bindings if python is enabled
2014-02-02 12:11 [Buildroot] [PATCH 0 of 9] Python depends on/select cleanup Thomas De Schampheleire
` (5 preceding siblings ...)
2014-02-02 12:11 ` [Buildroot] [PATCH 6 of 9] libdnet: " Thomas De Schampheleire
@ 2014-02-02 12:11 ` Thomas De Schampheleire
2014-02-02 12:11 ` [Buildroot] [PATCH 8 of 9] spice: automatically select python Thomas De Schampheleire
2014-02-02 12:11 ` [Buildroot] [PATCH 9 of 9] supervisor: " Thomas De Schampheleire
8 siblings, 0 replies; 10+ messages in thread
From: Thomas De Schampheleire @ 2014-02-02 12:11 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Buildroot] [PATCH 8 of 9] spice: automatically select python
2014-02-02 12:11 [Buildroot] [PATCH 0 of 9] Python depends on/select cleanup Thomas De Schampheleire
` (6 preceding siblings ...)
2014-02-02 12:11 ` [Buildroot] [PATCH 7 of 9] ola: " Thomas De Schampheleire
@ 2014-02-02 12:11 ` Thomas De Schampheleire
2014-02-02 12:11 ` [Buildroot] [PATCH 9 of 9] supervisor: " Thomas De Schampheleire
8 siblings, 0 replies; 10+ messages in thread
From: Thomas De Schampheleire @ 2014-02-02 12:11 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Buildroot] [PATCH 9 of 9] supervisor: automatically select python
2014-02-02 12:11 [Buildroot] [PATCH 0 of 9] Python depends on/select cleanup Thomas De Schampheleire
` (7 preceding siblings ...)
2014-02-02 12:11 ` [Buildroot] [PATCH 8 of 9] spice: automatically select python Thomas De Schampheleire
@ 2014-02-02 12:11 ` Thomas De Schampheleire
8 siblings, 0 replies; 10+ messages in thread
From: Thomas De Schampheleire @ 2014-02-02 12:11 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 10+ messages in thread