[Buildroot] libffi or the crazy world of toolchain options

[Buildroot] libffi or the crazy world of toolchain options

[Thomas Petazzoni]

Hello,

I got sick of having build issues related to libffi needs of threads,
of the absence of support for sh2a in libffi, so I did the work needed
to ensure that libffi would not be used anymore in those two cases.

This is a boring work, because libffi is mandatory for Python and
glib2, and glib2 has a crazy number of reverse dependencies that do
"select BR2_PACKAGE_LIBGLIB2", and therefore overstepping the
dependencies of glib2.

This patch, I hope, illustrate how crazy this story of "depends on"
needed for toolchain options has become. We need to find a solution
for this. Yann has proposed something (see
http://lists.busybox.net/pipermail/buildroot/2012-August/057144.html).

Opinions? My patch, or Yann's solution? Other solutions?

Thanks,

Thomas

[Buildroot] [PATCH] Adjust dependencies so that libffi is not used on unsupported systems

[Thomas Petazzoni]

The libffi library is not supported on SH2A systems and toolchains
without thread support. This library is mandatory for the Python
interpreter and the glib2 library, so both of these packages, and all
their reverse dependencies need to see their dependencies adjusted.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/atk/Config.in                         |    6 ++++--
 package/bluez_utils/Config.in                 |    3 ++-
 package/connman/Config.in                     |    3 ++-
 package/dbus-glib/Config.in                   |    6 ++++--
 package/docker/Config.in                      |    6 ++++--
 package/dstat/Config.in                       |    6 ++++--
 package/efl/libedbus/Config.in                |    1 +
 package/enchant/Config.in                     |    7 +++++--
 package/gamin/Config.in                       |    6 ++++--
 package/gdk-pixbuf/Config.in                  |    5 +++++
 package/glib-networking/Config.in             |    6 ++++--
 package/gmpc/Config.in                        |    6 ++++--
 package/gob2/Config.in                        |    6 ++++--
 package/gvfs/Config.in                        |    6 ++++--
 package/latencytop/Config.in                  |    6 ++++--
 package/libffi/Config.in                      |    2 ++
 package/libglib2/Config.in                    |    6 ++++--
 package/libgtk2/Config.in                     |    7 +++++--
 package/libmms/Config.in                      |    6 ++++--
 package/libmpd/Config.in                      |    6 ++++--
 package/libplayer/Config.in                   |    8 +++++---
 package/libsoup/Config.in                     |    6 ++++--
 package/lttng-babeltrace/Config.in            |    7 +++++--
 package/multimedia/gst-plugins-bad/Config.in  |    3 +++
 package/multimedia/gst-plugins-base/Config.in |   11 ++++++++---
 package/multimedia/gst-plugins-good/Config.in |    3 +++
 package/multimedia/gstreamer/Config.in        |    6 ++++--
 package/multimedia/mpd/Config.in              |    7 +++++--
 package/nbd/Config.in                         |    6 ++++--
 package/network-manager/Config.in             |    3 ++-
 package/ofono/Config.in                       |    3 ++-
 package/opencv/Config.in                      |    6 +++++-
 package/pango/Config.in                       |    7 +++++--
 package/pkg-config/Config.in                  |    6 ++++--
 package/python/Config.in                      |    6 ++++--
 package/shared-mime-info/Config.in            |    6 ++++--
 package/sshfs/Config.in                       |    6 ++++--
 package/sysprof/Config.in                     |    6 ++++--
 package/udev/Config.in                        |    2 ++
 package/vala/Config.in                        |    6 ++++--
 40 files changed, 155 insertions(+), 65 deletions(-)

diff --git a/package/atk/Config.in b/package/atk/Config.in
index 928fae7..cd448d6 100644
--- a/package/atk/Config.in
+++ b/package/atk/Config.in
@@ -2,8 +2,10 @@ config BR2_PACKAGE_ATK
 	bool "atk"
 	select BR2_PACKAGE_LIBGLIB2
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	help
 	  The ATK accessibility toolkit, needed to build GTK+-2.x.
 
-comment "atk requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "atk requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/bluez_utils/Config.in b/package/bluez_utils/Config.in
index d63284d..dade59c 100644
--- a/package/bluez_utils/Config.in
+++ b/package/bluez_utils/Config.in
@@ -1,7 +1,8 @@
 config BR2_PACKAGE_BLUEZ_UTILS
 	bool "bluez-utils"
 	depends on BR2_USE_WCHAR # libglib2
-	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus
+	depends on !BR2_sh2a # libglib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus, libglib2 -> libffi
 	select BR2_PACKAGE_DBUS
 	select BR2_PACKAGE_LIBGLIB2
 	help
diff --git a/package/connman/Config.in b/package/connman/Config.in
index 082b0ca..cf168e9 100644
--- a/package/connman/Config.in
+++ b/package/connman/Config.in
@@ -7,7 +7,8 @@ config BR2_PACKAGE_CONNMAN
 	depends on !(BR2_UCLIBC_VERSION_0_9_31 || BR2_UCLIBC_VERSION_0_9_32)
 	depends on BR2_USE_WCHAR # libglib2 and gnutls
 	depends on BR2_INET_IPV6
-	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus
+	depends on !BR2_sh2a # libglib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus, libglib2 -> libffi
 	help
 	  The Connection Manager (ConnMan) project provides a daemon for
 	  managing internet connections within embedded devices running
diff --git a/package/dbus-glib/Config.in b/package/dbus-glib/Config.in
index f1dab43..2b9bf80 100644
--- a/package/dbus-glib/Config.in
+++ b/package/dbus-glib/Config.in
@@ -2,11 +2,13 @@ config BR2_PACKAGE_DBUS_GLIB
 	bool "dbus-glib"
 	depends on BR2_PACKAGE_DBUS
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	help
 	  GLib bindings for D-Bus.
 
 	  http://www.freedesktop.org/software/dbus
 
-comment "dbus-glib requires a toolchain with WCHAR support"
-	depends on BR2_PACKAGE_DBUS && !BR2_USE_WCHAR
+comment "dbus-glib requires a toolchain with WCHAR and thread support"
+	depends on BR2_PACKAGE_DBUS && (!BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS)
diff --git a/package/docker/Config.in b/package/docker/Config.in
index 75bf5be..81fdc22 100644
--- a/package/docker/Config.in
+++ b/package/docker/Config.in
@@ -2,11 +2,13 @@ config BR2_PACKAGE_DOCKER
 	bool "docker"
 	depends on BR2_PACKAGE_XORG7
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	help
 	  a system tray dock for X
 
 	  http://icculus.org/openbox/2/docker
 
-comment "docker requires a toolchain with WCHAR support"
-	depends on BR2_PACKAGE_XORG7 && !BR2_USE_WCHAR
+comment "docker requires a toolchain with WCHAR and thread support"
+	depends on BR2_PACKAGE_XORG7 && (!BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS)
diff --git a/package/dstat/Config.in b/package/dstat/Config.in
index 1439c8b..4c02fb5 100644
--- a/package/dstat/Config.in
+++ b/package/dstat/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_DSTAT
 	bool "dstat"
 	depends on BR2_USE_WCHAR # python
+	depends on !BR2_sh2a # python -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # python -> libffi
 	select BR2_PACKAGE_PYTHON
 	help
 	  Dstat, written in Python, is a versatile replacement for vmstat,
@@ -19,5 +21,5 @@ config BR2_PACKAGE_DSTAT
 
 	  http://dag.wieers.com/home-made/dstat/
 
-comment "dstat requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "dstat requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/efl/libedbus/Config.in b/package/efl/libedbus/Config.in
index 985939e..fbcf1ab 100644
--- a/package/efl/libedbus/Config.in
+++ b/package/efl/libedbus/Config.in
@@ -16,6 +16,7 @@ if BR2_PACKAGE_LIBEDBUS
 config BR2_PACKAGE_LIBEDBUS_BLUEZ
 	bool "bluez support"
 	select BR2_PACKAGE_BLUEZ_UTILS
+	depends on !BR2_sh2a # bluez -> glib2 -> libffi
 	help
 	  Bluetooth support.
 
diff --git a/package/enchant/Config.in b/package/enchant/Config.in
index 33f36db..b659eeb 100644
--- a/package/enchant/Config.in
+++ b/package/enchant/Config.in
@@ -2,6 +2,8 @@ config BR2_PACKAGE_ENCHANT
 	bool "enchant"
 	depends on BR2_INSTALL_LIBSTDCPP
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	help
 	  Enchant is a spell-checking library that provides a consistent
@@ -9,5 +11,6 @@ config BR2_PACKAGE_ENCHANT
 
 	  http://www.abisource.com/projects/enchant/
 
-comment "enchant requires a toolchain with C++ and WCHAR support enabled"
-	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR
+comment "enchant requires a toolchain with C++, WCHAR and thread support enabled"
+	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || \
+		!BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/gamin/Config.in b/package/gamin/Config.in
index 3ede2e4..f3c1377 100644
--- a/package/gamin/Config.in
+++ b/package/gamin/Config.in
@@ -1,11 +1,13 @@
 config BR2_PACKAGE_GAMIN
 	bool "gamin"
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	help
 	  the File Alteration Monitor
 
 	  http://www.gnome.org/~veillard/gamin/sources
 
-comment "gamin requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "gamin requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/gdk-pixbuf/Config.in b/package/gdk-pixbuf/Config.in
index 28a0f12..76964d4 100644
--- a/package/gdk-pixbuf/Config.in
+++ b/package/gdk-pixbuf/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_GDK_PIXBUF
 	bool "gdk-pixbuf"
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT
 	select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT
@@ -10,3 +12,6 @@ config BR2_PACKAGE_GDK_PIXBUF
 	  and the GLib, to integrate well with GNOME applications.
 
 	  http://www.gtk.org/
+
+comment "gdb-pixbuf requires WCHAR and thread support in toolchain"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/glib-networking/Config.in b/package/glib-networking/Config.in
index 16f0d4a..8a5369c 100644
--- a/package/glib-networking/Config.in
+++ b/package/glib-networking/Config.in
@@ -1,11 +1,13 @@
 config BR2_PACKAGE_GLIB_NETWORKING
 	bool "glib-networking"
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT
 	select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT
 	help
 	  Network-related GIO modules for glib.
 
-comment "glib-networking requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "glib-networking requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/gmpc/Config.in b/package/gmpc/Config.in
index f86945c..a2ae32b 100644
--- a/package/gmpc/Config.in
+++ b/package/gmpc/Config.in
@@ -2,6 +2,8 @@ config BR2_PACKAGE_GMPC
 	bool "gmpc"
 	depends on BR2_PACKAGE_LIBGTK2
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	depends on BR2_PACKAGE_XORG7
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE
@@ -20,5 +22,5 @@ config BR2_PACKAGE_GMPC
 
 	  http://gmpcwiki.sarine.nl/index.php?title=GMPC
 
-comment "gmpc requires a toolchain with WCHAR support"
-	depends on BR2_PACKAGE_LIBGTK2 && !BR2_USE_WCHAR
+comment "gmpc requires a toolchain with WCHAR and thread support"
+	depends on BR2_PACKAGE_LIBGTK2 && (!BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS)
diff --git a/package/gob2/Config.in b/package/gob2/Config.in
index cbe30d6..e10b075 100644
--- a/package/gob2/Config.in
+++ b/package/gob2/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_GOB2
 	bool "gob2"
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	# m4 uses fork(), so does bison then
 	depends on BR2_USE_MMU
 	select BR2_PACKAGE_LIBGLIB2
@@ -13,5 +15,5 @@ config BR2_PACKAGE_GOB2
 
 	  http://www.jirka.org/gob.html
 
-comment "gob2 requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "gob2 requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/gvfs/Config.in b/package/gvfs/Config.in
index 87f9a03..e2d53bc 100644
--- a/package/gvfs/Config.in
+++ b/package/gvfs/Config.in
@@ -2,6 +2,8 @@ config BR2_PACKAGE_GVFS
 	bool "gvfs"
 	depends on BR2_LARGEFILE
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_DBUS
 	select BR2_PACKAGE_SHARED_MIME_INFO
@@ -14,5 +16,5 @@ config BR2_PACKAGE_GVFS
 
 	  http://en.wikipedia.org/wiki/GVFS
 
-comment "gvfs requires a toolchain with LARGEFILE and WCHAR support"
-	depends on !BR2_LARGEFILE || !BR2_USE_WCHAR
+comment "gvfs requires a toolchain with LARGEFILE, WCHAR and thread support"
+	depends on !BR2_LARGEFILE || !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/latencytop/Config.in b/package/latencytop/Config.in
index 12176c0..e9c3a65 100644
--- a/package/latencytop/Config.in
+++ b/package/latencytop/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_LATENCYTOP
 	bool "latencytop"
 	depends on BR2_USE_WCHAR
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_NCURSES
 	select BR2_PACKAGE_LIBGLIB2
 	help
@@ -19,5 +21,5 @@ config BR2_PACKAGE_LATENCYTOP
 
 	  http://www.latencytop.org
 
-comment "latencytop requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "latencytop requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/libffi/Config.in b/package/libffi/Config.in
index 7211f8f..0c4d328 100644
--- a/package/libffi/Config.in
+++ b/package/libffi/Config.in
@@ -1,5 +1,7 @@
 config BR2_PACKAGE_LIBFFI
 	bool "libffi"
+	depends on !BR2_sh2a
+	depends on BR2_TOOLCHAIN_HAS_THREADS
 	help
 	  The libffi library provides a portable, high level
 	  programming interface to various calling conventions. This
diff --git a/package/libglib2/Config.in b/package/libglib2/Config.in
index d1d7231..518d314 100644
--- a/package/libglib2/Config.in
+++ b/package/libglib2/Config.in
@@ -6,10 +6,12 @@ config BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_LIBFFI
 	select BR2_PACKAGE_ZLIB
 	depends on BR2_USE_WCHAR # gettext
+	depends on !BR2_sh2a # libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # libffi
 	help
 	  Low-level core library that forms the basis of GTK+ and GNOME.
 
 	  http://www.gtk.org/
 
-comment "libglib2 requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "libglib2 requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/libgtk2/Config.in b/package/libgtk2/Config.in
index efaf12f..5da724e 100644
--- a/package/libgtk2/Config.in
+++ b/package/libgtk2/Config.in
@@ -10,6 +10,8 @@ config BR2_PACKAGE_LIBGTK2
 	select BR2_PACKAGE_GDK_PIXBUF
 	depends on BR2_PACKAGE_XORG7||BR2_PACKAGE_DIRECTFB
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	depends on BR2_INSTALL_LIBSTDCPP # pango
 	help
 	  The GTK+ version 2 graphical user interface library
@@ -23,5 +25,6 @@ config BR2_PACKAGE_LIBGTK2_DEMO
 	  The GTK+ source base contains a gtk-demo program. This
 	  option allows to install this program to the target.
 
-comment "libgtk2 requires a toolchain with WCHAR and C++ support"
-	depends on !BR2_USE_WCHAR || !BR2_INSTALL_LIBSTDCPP
+comment "libgtk2 requires a toolchain with WCHAR, C++ and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_INSTALL_LIBSTDCPP || \
+		!BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/libmms/Config.in b/package/libmms/Config.in
index 17cb406..be00360 100644
--- a/package/libmms/Config.in
+++ b/package/libmms/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_LIBMMS
 	bool "libmms"
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	help
           LibMMS is a common library for parsing mms:// and mmsh://
@@ -11,5 +13,5 @@ config BR2_PACKAGE_LIBMMS
 
 	  http://launchpad.net/libmms
 
-comment "libmms requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "libmms requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/libmpd/Config.in b/package/libmpd/Config.in
index 9259c19..e1ba0e4 100644
--- a/package/libmpd/Config.in
+++ b/package/libmpd/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_LIBMPD
 	bool "libmpd"
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE
 	help
@@ -10,5 +12,5 @@ config BR2_PACKAGE_LIBMPD
 
 	  http://gmpcwiki.sarine.nl/index.php?title=Libmpd
 
-comment "libmpd requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "libmpd requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/libplayer/Config.in b/package/libplayer/Config.in
index fe851ac..0f587df 100644
--- a/package/libplayer/Config.in
+++ b/package/libplayer/Config.in
@@ -15,11 +15,13 @@ config BR2_PACKAGE_LIBPLAYER_MPLAYER
 
 config BR2_PACKAGE_LIBPLAYER_GSTREAMER
 	bool "gstreamer backend"
-	depends on BR2_USE_WCHAR # glib2
+	depends on BR2_USE_WCHAR # gstreamer -> glib2
+	depends on !BR2_sh2a # gstreamer -> glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # gstreamer -> glib2 -> libffi
 	select BR2_PACKAGE_GSTREAMER
 
-comment "gstreamer backend requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "gstreamer backend requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
 
 config BR2_PACKAGE_LIBPLAYER_PYTHON
 	depends on BR2_PACKAGE_PYTHON
diff --git a/package/libsoup/Config.in b/package/libsoup/Config.in
index f40625d..da03819 100644
--- a/package/libsoup/Config.in
+++ b/package/libsoup/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_LIBSOUP
 	bool "libsoup"
 	depends on BR2_USE_WCHAR # glib2 and gnutls
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBXML2
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT
@@ -20,5 +22,5 @@ config BR2_PACKAGE_LIBSOUP_SSL
 	help
 	  Enable HTTPS (SSL) support.
 
-comment "libsoup requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "libsoup requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/lttng-babeltrace/Config.in b/package/lttng-babeltrace/Config.in
index 6f47304..7610669 100644
--- a/package/lttng-babeltrace/Config.in
+++ b/package/lttng-babeltrace/Config.in
@@ -9,6 +9,8 @@ config BR2_PACKAGE_LTTNG_BABELTRACE
 	depends on BR2_USE_WCHAR
 	# util-linux depends on largefile support
 	depends on BR2_LARGEFILE
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	help
 	  Babeltrace is part of the LTTng 2.x project.
 
@@ -26,5 +28,6 @@ config BR2_PACKAGE_LTTNG_BABELTRACE
 
 	  http://lttng.org
 
-comment "lttng-babeltrace needs WCHAR and LARGEFILE support"
-	depends on BR2_PACKAGE_LTTNG_TOOLS && !(BR2_USE_WCHAR || BR2_LARGEFILE)
+comment "lttng-babeltrace needs WCHAR, LARGEFILE and thread support"
+	depends on BR2_PACKAGE_LTTNG_TOOLS && \
+		!(BR2_USE_WCHAR || BR2_LARGEFILE || BR2_TOOLCHAIN_HAS_THREADS)
diff --git a/package/multimedia/gst-plugins-bad/Config.in b/package/multimedia/gst-plugins-bad/Config.in
index cb50fbd..b02e2da 100644
--- a/package/multimedia/gst-plugins-bad/Config.in
+++ b/package/multimedia/gst-plugins-bad/Config.in
@@ -271,6 +271,9 @@ config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_FBDEV
 
 config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_LIBMMS
 	bool "libmms"
+	depends on BR2_USE_WCHAR # libmms -> glib2
+	depends on !BR2_sh2a # libmms -> glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # libmms -> glib2 -> libffi
 	select BR2_PACKAGE_LIBMMS
 
 config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_NEON
diff --git a/package/multimedia/gst-plugins-base/Config.in b/package/multimedia/gst-plugins-base/Config.in
index 5d82533..a6ba9ae 100644
--- a/package/multimedia/gst-plugins-base/Config.in
+++ b/package/multimedia/gst-plugins-base/Config.in
@@ -79,11 +79,16 @@ config BR2_PACKAGE_GST_PLUGINS_BASE_PLUGIN_OGG
 
 config BR2_PACKAGE_GST_PLUGINS_BASE_PLUGIN_PANGO
 	bool "pango font renderer"
-	depends on BR2_INSTALL_LIBSTDCPP
+	depends on BR2_USE_WCHAR # pango -> glib2
+	depends on BR2_INSTALL_LIBSTDCPP # pango -> freetype support
+	depends on !BR2_sh2a # pango -> glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # pango -> glib2 -> libffi
 	select BR2_PACKAGE_PANGO
 
-comment "pango plugin requires a toolchain with C++ support"
-	depends on !BR2_INSTALL_LIBSTDCPP
+comment "pango plugin requires a toolchain with C++, wchar and thread support"
+	depends on !BR2_INSTALL_LIBSTDCPP || \
+		!BR2_USE_WCHAR || \
+		!BR2_TOOLCHAIN_HAS_THREADS
 
 config BR2_PACKAGE_GST_PLUGINS_BASE_PLUGIN_THEORA
 	bool "theora (*.ogg video)"
diff --git a/package/multimedia/gst-plugins-good/Config.in b/package/multimedia/gst-plugins-good/Config.in
index 33ecb5c..998e2c5 100644
--- a/package/multimedia/gst-plugins-good/Config.in
+++ b/package/multimedia/gst-plugins-good/Config.in
@@ -198,6 +198,9 @@ config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_PULSE
 
 config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_SOUPHTTPSRC
 	bool "souphttpsrc (http client)"
+	depends on BR2_USE_WCHAR # libsoup -> glib2 and gnutls
+	depends on !BR2_sh2a # libsoup -> glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # libsoup -> glib2 -> libffi
 	select BR2_PACKAGE_LIBSOUP
 
 config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_SPEEX
diff --git a/package/multimedia/gstreamer/Config.in b/package/multimedia/gstreamer/Config.in
index 4d279b8..4370902 100644
--- a/package/multimedia/gstreamer/Config.in
+++ b/package/multimedia/gstreamer/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_GSTREAMER
 	bool "gstreamer"
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	help
 	  GStreamer is an open source multimedia framework.
@@ -16,5 +18,5 @@ config BR2_PACKAGE_GSTREAMER_GST_DEBUG
 	  in gstreamer. This has limited CPU overhead, but does
 	  increase the rootfs size somewhat.
 
-comment "gstreamer requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "gstreamer requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/multimedia/mpd/Config.in b/package/multimedia/mpd/Config.in
index c7c0cd7..f0adaac 100644
--- a/package/multimedia/mpd/Config.in
+++ b/package/multimedia/mpd/Config.in
@@ -2,6 +2,8 @@ menuconfig BR2_PACKAGE_MPD
 	bool "mpd"
 	depends on BR2_INSTALL_LIBSTDCPP
 	depends on BR2_USE_WCHAR
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE
 	select BR2_PACKAGE_MPD_TREMOR if !(BR2_PACKAGE_MPD_MAD || BR2_PACKAGE_MPD_MPG123 || BR2_PACKAGE_MPD_VORBIS || BR2_PACKAGE_MPD_WAVPACK || BR2_PACKAGE_MPD_FLAC || BR2_PACKAGE_MPD_MUSEPACK || BR2_PACKAGE_MPD_FFMPEG)
@@ -174,5 +176,6 @@ config BR2_PACKAGE_MPD_WAVPACK
 
 endif
 
-comment "mpd requires a toolchain with C++ and WCHAR support"
-	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR
+comment "mpd requires a toolchain with C++, WCHAR and thread support"
+	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || \
+		!BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/nbd/Config.in b/package/nbd/Config.in
index 6e92f93..7604a19 100644
--- a/package/nbd/Config.in
+++ b/package/nbd/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_NBD
 	bool "nbd"
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	help
 	  NBD is a set of utilities to configure network block devices,
@@ -10,8 +12,8 @@ config BR2_PACKAGE_NBD
 
 	  http://nbd.sf.net/
 
-comment "nbd requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "nbd requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
 
 if BR2_PACKAGE_NBD
 
diff --git a/package/network-manager/Config.in b/package/network-manager/Config.in
index 3f01fef..24c9431 100644
--- a/package/network-manager/Config.in
+++ b/package/network-manager/Config.in
@@ -5,7 +5,8 @@ config BR2_PACKAGE_NETWORK_MANAGER
 	depends on BR2_INET_IPV6
 	depends on BR2_LARGEFILE # acl
 	depends on BR2_USE_WCHAR # libglib2 and gnutls
-	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus
+	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus, dbus-glib -> glib2, libffi
+	depends on !BR2_sh2a # dbus-glib -> glib2 -> libffi
 	select BR2_PACKAGE_DBUS_GLIB
 	select BR2_PACKAGE_UDEV
 	select BR2_PACKAGE_UDEV_ALL_EXTRAS
diff --git a/package/ofono/Config.in b/package/ofono/Config.in
index 74c8b53..379c5c4 100644
--- a/package/ofono/Config.in
+++ b/package/ofono/Config.in
@@ -1,7 +1,8 @@
 config BR2_PACKAGE_OFONO
 	bool "ofono"
 	depends on BR2_USE_WCHAR # gettext/libglib2
-	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus, glib2 -> libffi
 	select BR2_PACKAGE_LIBCAP_NG
 	select BR2_PACKAGE_DBUS
 	select BR2_PACKAGE_LIBGLIB2
diff --git a/package/opencv/Config.in b/package/opencv/Config.in
index 3e9ead6..6e5083d 100644
--- a/package/opencv/Config.in
+++ b/package/opencv/Config.in
@@ -139,7 +139,9 @@ comment "ffmpeg support requires a toolchain with LARGEFILE and IPV6 support"
 
 config BR2_PACKAGE_OPENCV_WITH_GSTREAMER
 	bool "gstreamer support"
-	depends on BR2_USE_WCHAR
+	depends on BR2_USE_WCHAR # gstreamer -> glib2
+	depends on !BR2_sh2a # gstreamer -> glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # gstreamer -> glib2 -> libffi
 	select BR2_PACKAGE_GSTREAMER
 	select BR2_PACKAGE_GST_PLUGINS_BASE
 	select BR2_PACKAGE_GST_PLUGINS_BASE_PLUGIN_APP
@@ -149,6 +151,8 @@ config BR2_PACKAGE_OPENCV_WITH_GTK
 	depends on BR2_PACKAGE_XORG7||BR2_PACKAGE_DIRECTFB
 	depends on BR2_USE_WCHAR
 	depends on BR2_INSTALL_LIBSTDCPP
+	depends on !BR2_sh2a # gtk2 -> glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # gtk2 -> glib2 -> libffi
 	select BR2_PACKAGE_LIBGTK2
 
 config BR2_PACKAGE_OPENCV_WITH_JPEG
diff --git a/package/pango/Config.in b/package/pango/Config.in
index 923c3d4..06e4d43 100644
--- a/package/pango/Config.in
+++ b/package/pango/Config.in
@@ -2,6 +2,8 @@ config BR2_PACKAGE_PANGO
 	bool "pango"
 	depends on BR2_USE_WCHAR # glib2
 	depends on BR2_INSTALL_LIBSTDCPP # freetype support
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_EXPAT
 	select BR2_PACKAGE_CAIRO
@@ -16,5 +18,6 @@ config BR2_PACKAGE_PANGO
 
 	  http://www.pango.org/
 
-comment "pango requires a toolchain with WCHAR and C++ support"
-	depends on !BR2_USE_WCHAR || !BR2_INSTALL_LIBSTDCPP
+comment "pango requires a toolchain with WCHAR, C++ and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_INSTALL_LIBSTDCPP || \
+		!BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/pkg-config/Config.in b/package/pkg-config/Config.in
index eae0a21..3879f2a 100644
--- a/package/pkg-config/Config.in
+++ b/package/pkg-config/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_PKG_CONFIG
 	bool "pkg-config"
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	help
 	  pkg-config is a system for managing library compile/link
@@ -10,5 +12,5 @@ config BR2_PACKAGE_PKG_CONFIG
 
 	  http://www.freedesktop.org/software/pkgconfig/
 
-comment "pkg-config requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "pkg-config requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/python/Config.in b/package/python/Config.in
index 11aa267..e16287c 100644
--- a/package/python/Config.in
+++ b/package/python/Config.in
@@ -2,13 +2,15 @@ config BR2_PACKAGE_PYTHON
 	bool "python"
 	depends on BR2_USE_WCHAR
 	select BR2_PACKAGE_LIBFFI
+	depends on !BR2_sh2a # libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # libffi
 	help
 	  The python language interpreter.
 
 	  http://www.python.org/
 
-comment "python requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "python requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
 
 if BR2_PACKAGE_PYTHON
 
diff --git a/package/shared-mime-info/Config.in b/package/shared-mime-info/Config.in
index b08c1fd..8802755 100644
--- a/package/shared-mime-info/Config.in
+++ b/package/shared-mime-info/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_SHARED_MIME_INFO
 	bool "shared-mime-info"
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_LIBXML2
 	help
@@ -10,5 +12,5 @@ config BR2_PACKAGE_SHARED_MIME_INFO
 
 	  http://freedesktop.org/wiki/Software/shared-mime-info
 
-comment "shared-mime-info requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "shared-mime-info requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/sshfs/Config.in b/package/sshfs/Config.in
index 73d552f..ce91866 100644
--- a/package/sshfs/Config.in
+++ b/package/sshfs/Config.in
@@ -8,10 +8,12 @@ config BR2_PACKAGE_SSHFS
 	select BR2_PACKAGE_OPENSSH
 	depends on BR2_LARGEFILE
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	help
 	  FUSE filesystem client based on the SSH File Transfer Protocol.
 
 	  http://fuse.sourceforge.net/sshfs.html
 
-comment "sshfs requires a toolchain with LARGEFILE and WCHAR support"
-	depends on !BR2_LARGEFILE || !BR2_USE_WCHAR
+comment "sshfs requires a toolchain with LARGEFILE, WCHAR and thread support"
+	depends on !BR2_LARGEFILE || !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/sysprof/Config.in b/package/sysprof/Config.in
index 513a32c..8c29084 100644
--- a/package/sysprof/Config.in
+++ b/package/sysprof/Config.in
@@ -2,6 +2,8 @@ config BR2_PACKAGE_SYSPROF
 	bool "sysprof"
 	select BR2_PACKAGE_LIBGLIB2
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	# In its util.h file, sysprof contains architecture-specific
 	# code
 	depends on BR2_i386 || BR2_x86_64 || BR2_powerpc || BR2_sh4a || BR2_sh4aeb
@@ -20,5 +22,5 @@ config BR2_PACKAGE_SYSPROF_GUI
 	help
 	  GUI for the sysprof system-wide statistical profiler.
 
-comment "sysprof requires a toolchain with WCHAR support"
-        depends on !BR2_USE_WCHAR
+comment "sysprof requires a toolchain with WCHAR and thread support"
+        depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/udev/Config.in b/package/udev/Config.in
index d3244d1..b07b0f4 100644
--- a/package/udev/Config.in
+++ b/package/udev/Config.in
@@ -3,6 +3,8 @@ config BR2_PACKAGE_UDEV
 	depends on BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV
 	depends on BR2_LARGEFILE # util-linux
 	depends on BR2_USE_WCHAR # util-linux
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_UTIL_LINUX
 	select BR2_PACKAGE_UTIL_LINUX_LIBBLKID
 	select BR2_PACKAGE_KMOD
diff --git a/package/vala/Config.in b/package/vala/Config.in
index 89b4459..0c97958 100644
--- a/package/vala/Config.in
+++ b/package/vala/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_VALA
 	bool "vala"
 	depends on BR2_USE_WCHAR # glib2
+	depends on !BR2_sh2a # glib2 -> libffi
+	depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 -> libffi
 	select BR2_PACKAGE_LIBGLIB2
 	select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE
 	select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT_IF_LOCALE
@@ -10,5 +12,5 @@ config BR2_PACKAGE_VALA
 
 	  http://live.gnome.org/Vala
 
-comment "vala requires a toolchain with WCHAR support"
-	depends on !BR2_USE_WCHAR
+comment "vala requires a toolchain with WCHAR and thread support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
-- 
1.7.9.5

[Buildroot] libffi or the crazy world of toolchain options

[Yann E. MORIN]

Thomas, All,

On Saturday 25 August 2012 17:06:05 Thomas Petazzoni wrote:
> I got sick of having build issues related to libffi needs of threads,
> of the absence of support for sh2a in libffi, so I did the work needed
> to ensure that libffi would not be used anymore in those two cases.
> 
> This is a boring work, because libffi is mandatory for Python and
> glib2, and glib2 has a crazy number of reverse dependencies that do
> "select BR2_PACKAGE_LIBGLIB2", and therefore overstepping the
> dependencies of glib2.
> 
> This patch, I hope, illustrate how crazy this story of "depends on"
> needed for toolchain options has become. We need to find a solution
> for this. Yann has proposed something (see
> http://lists.busybox.net/pipermail/buildroot/2012-August/057144.html).
> 
> Opinions? My patch, or Yann's solution? Other solutions?

I'm sorry to say that, but pushing dependencies down to every package is
ugly.

What would happen when/if hte next libffi release does support sh2a?
You'd have to undo most of this work with another thousands-packages patch.

Today, I'll be working on my proposal (eg. the BR2_PKG_XX_AVAILABLE stuff),
and will post a patchset.

Thus, we'll be able to compare.

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

[Buildroot] libffi or the crazy world of toolchain options

[Yann E. MORIN]

Thomas, All,

On Sunday 26 August 2012 12:23:46 Yann E. MORIN wrote:
> On Saturday 25 August 2012 17:06:05 Thomas Petazzoni wrote:
> > This patch, I hope, illustrate how crazy this story of "depends on"
> > needed for toolchain options has become. We need to find a solution
> > for this. Yann has proposed something (see
> > http://lists.busybox.net/pipermail/buildroot/2012-August/057144.html).
> > 
> > Opinions? My patch, or Yann's solution? Other solutions?
[--SNIP--]
> Today, I'll be working on my proposal (eg. the BR2_PKG_XX_AVAILABLE stuff),
> and will post a patchset.

OK, now I have a shell+awk script (pkg-avail, attached) that:
  - adds a BR2_PACKAGE_XXX_AVAILABLE symbol for all packages
  - moves packages dependencies to that symbol
  - adds a single dependency against that symbol to the corresponding
    BR2_PACKAGE_XXX /main/ symbol

and a second shell script (pkg-avail-test, attached too) that:
  - runs a batch of randconfig before the changes, and saves the
    generated .config files
  - applies the changes
  - uses the previous batch of randconfigs as defconfig files
  - compares the initial .config with the new .config

Note that the pkg-avail-test script does a few tricks to be able to compare
before and after the change:
  - removes the commented date-line
  - fakes any required DEFCONFIG files (eg. for barebox, the kernel, the
    ct-ng bachkend)
  - removes the _AVAILABLE symbols in new .config files

So far, I've run 10.000 iterations (took ~1h), and I saw no difference.

(
  What I saw, however, is that there are at least two 'select' on packages
  that have 'unmet direct dependencies':
    - (BR2_INIT_SYSV) selects BR2_PACKAGE_SYSVINIT which has unmet direct
      dependencies (BR2_PACKAGE_BUSYBOX_SHOW_OTHERS)
    - (BR2_PACKAGE_COLLECTD_RRDTOOL) selects BR2_PACKAGE_RRDTOOL which has
      unmet direct dependencies (BR2_USE_WCHAR)
  I hope that this can be solved by this on-going change, but I'll anyway
  try to send a fix for those two so it can go in 2012.08.
)

What's left, now, is to change each dependency on a package /main/ symbol
to a dependency on the corresponding _AVAILABLE symbol, plus a select on
the the /main/ symbol. I hope to update my scripts with this functionality.
I definitely do not want to manually review hundreds of packages! ;-)

Both scripts use stgit to manage the stack queue of changes (I heavily
use stgit, it eases things for me).

I am not posting the corresponding patchset, because:
  - it is really big
  - it's not final
  - anyone can experiment with my two scripts

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.  |
'------------------------------^-------^------------------^--------------------'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pkg-avail
Type: application/x-shellscript
Size: 2482 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120826/fa42b733/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pkg-avail-test
Type: application/x-shellscript
Size: 1514 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120826/fa42b733/attachment-0001.bin>

[Buildroot] libffi or the crazy world of toolchain options

[Yann E. MORIN]

Thomas, All,

On Sunday 26 August 2012 22:40:50 Yann E. MORIN wrote:
> What's left, now, is to change each dependency on a package /main/ symbol
> to a dependency on the corresponding _AVAILABLE symbol, plus a select on
> the the /main/ symbol. I hope to update my scripts with this functionality.
> I definitely do not want to manually review hundreds of packages! ;-)

Well, find attached an updated pkg-avail script that does just that.

Please note however that the script is not bullet-proof, neither when adding
the _AVAILABLE symbols, nor when using them. It avoids mangling simple cases
(such as: "depends on PKG_FOO||PKG_BAR" and stuff like that) and thus misses
some of the dependencies, but may still butcher other places. :-/

Enough for today, more tomorrow...

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.  |
'------------------------------^-------^------------------^--------------------'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pkg-avail
Type: application/x-shellscript
Size: 4775 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120827/2139b68a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pkg-avail-test
Type: application/x-shellscript
Size: 1514 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120827/2139b68a/attachment-0001.bin>

[Buildroot] libffi or the crazy world of toolchain options

[Thomas Petazzoni]

Le Sun, 26 Aug 2012 12:23:46 +0200,
"Yann E. MORIN" <yann.morin.1998@free.fr> a ?crit :

> I'm sorry to say that, but pushing dependencies down to every package is
> ugly.

I know :) My intent by sending this patch was to clearly show how ugly
it is in practice, and demonstrate that we need another solution. Seems
like it encouraged you to work on your alternate proposal, which was
the intended effect :)

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] libffi or the crazy world of toolchain options

[Yann E. MORIN]

Thomas, All,

On Monday 27 August 2012 00:43:26 Yann E. MORIN wrote:
> On Sunday 26 August 2012 22:40:50 Yann E. MORIN wrote:
> > What's left, now, is to change each dependency on a package /main/ symbol
> > to a dependency on the corresponding _AVAILABLE symbol, plus a select on
> > the the /main/ symbol. I hope to update my scripts with this functionality.
> > I definitely do not want to manually review hundreds of packages! ;-)
> 
> Well, find attached an updated pkg-avail script that does just that.
> 
> Please note however that the script is not bullet-proof, neither when adding
> the _AVAILABLE symbols, nor when using them. It avoids mangling simple cases
> (such as: "depends on PKG_FOO||PKG_BAR" and stuff like that) and thus misses
> some of the dependencies, but may still butcher other places. :-/
> 
> Enough for today, more tomorrow...

For those interested, I've posted two patches that can be applied ontop
commit bc753d3ca243bcda35d567465ee649ecee3ef236 :

    http://ymorin.is-a-geek.org/download/tmp/

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

[Buildroot] libffi or the crazy world of toolchain options

[Yann E. MORIN]

Thomas, All,

On Sunday 26 August 2012 22:40:50 Yann E. MORIN wrote:
> On Sunday 26 August 2012 12:23:46 Yann E. MORIN wrote:
> OK, now I have a shell+awk script (pkg-avail, attached) that:
>   - adds a BR2_PACKAGE_XXX_AVAILABLE symbol for all packages
>   - moves packages dependencies to that symbol
>   - adds a single dependency against that symbol to the corresponding
>     BR2_PACKAGE_XXX /main/ symbol

OK, this is iteration 3 of the script.

It now runs three pases:

1) - introduces a BR2_PACKAGE_XXX_AVAILABLE symbol
   - moves all the package dependencies to this symbol
   - has the package depends only on this symbol

2) - transforms all 'depends on BR2_PACKAGE_XXX' into a dependency
     on the corresponding _AVAILABLE symbol
   - adds a select on the corresponding package

3) - checks and fixes 'select BR2_PACKAGE_XXX' that does not have a
     corresponding 'depends on BR2_PACKAGE_XXX_AVAILABLE'

NOTE: the coverage of this script is NOT 100%. Some manual inspection
and fixes are still required.

Pass 1 treats all 817 packages. After a quick glance, all appears OK,
but a more thorough analysis must be conducted.

Pass 2 finds 67 packages that needs munging. There are a few packages
left over, becasue they ahve constructs like
    depends on PKG_FOO || PKG_BAR

Pass 3 finds 401 packages that 'select' packages without a corresponding
'depends on' on the _AVAILABLE symbol. A casual glance found that pass
to be pretty OK, although a complete analysis has not ben done so far.

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.  |
'------------------------------^-------^------------------^--------------------'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pkg-avail
Type: application/x-shellscript
Size: 6962 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120830/6ae428c6/attachment.bin>

[Buildroot] libffi or the crazy world of toolchain options

[Arnout Vandecappelle]

On 08/30/12 00:53, Yann E. MORIN wrote:
> Thomas, All,
>
> On Sunday 26 August 2012 22:40:50 Yann E. MORIN wrote:
> > On Sunday 26 August 2012 12:23:46 Yann E. MORIN wrote:
> > OK, now I have a shell+awk script (pkg-avail, attached) that:
> >    - adds a BR2_PACKAGE_XXX_AVAILABLE symbol for all packages
> >    - moves packages dependencies to that symbol
> >    - adds a single dependency against that symbol to the corresponding
> >      BR2_PACKAGE_XXX /main/ symbol
>
> OK, this is iteration 3 of the script.
>
> It now runs three pases:
>
> 1) - introduces a BR2_PACKAGE_XXX_AVAILABLE symbol
>     - moves all the package dependencies to this symbol
>     - has the package depends only on this symbol
  So that means the XXX_AVAILABLE is there even if the package has no
dependencies? I'm not sure I like that... It means the simplest packages
become more complex (only to make a few complex cases simpler).
A patch with a shortstat that adds 4500+ lines, that can't be right :-)

  Take the example of transmission: the size of its Config.in doubles, but
the real dependency is IPV6.  Adding all those "depends on ..._AVAILABLE"
which are always true only hide the real restriction here.

  So I propose to remove the _AVAILABLE symbols for packages that don't
have actual dependencies.  At the moment, those are easy to find because
the dependencies are present directly in the package (but of course the
intention is to remove those direct dependencies if they're actually due to
an indirect dependency).

=> In pass 1, only create the _AVAILABLE symbol if there is a depends on.
Also log in a file for which packages the _AVAILABLE was created

=> in pass 2 and 3, only execute the transformation if the _AVAILABLE
exists.


  Note that the disadvantage of restricting the _AVAILABLE to packages
that really need it, is that there's more work when a package acquires its first
toolchain dependency. Indeed, you have to add the _AVAILABLE symbol,
and look for all packages that select this one and add an _AVAILABLE
dependency. However, I think it doesn't often occur that a package
acquires a new (toolchain) dependency, and when it does it usually already
has an existing dependency (cfr. libglib2, python, xorg7, efl).  So, even
the libffi case wouldn't have cost much effort.


> 2) - transforms all 'depends on BR2_PACKAGE_XXX' into a dependency
>       on the corresponding _AVAILABLE symbol
>     - adds a select on the corresponding package
  Actually I don't think we want this step.  The "depends on BR2_PACKAGE_XXX"
construct is used to hide packages that depend on a super-feature, like
X11 or python. In other cases, it's used to reduce the size of the menus where
relevant; e.g. dbus-glib is only relevant if you have dbus. This isn't perfectly
clear-cut, but it shouldn't be done mechanically.

>
> 3) - checks and fixes 'select BR2_PACKAGE_XXX' that does not have a
>       corresponding 'depends on BR2_PACKAGE_XXX_AVAILABLE'

  What is missing as a fourth step is the removal of the dependencies which are
actually due to transitive dependencies. They can be detected because normally
we write
depends on BR2_USE_WCHAR # glib2
in such a situation.  But again, I wouldn't do this mechanically. There are only
85 of these comments, and you have the "depends on ..._AVAILABLE" below
to verify if the transitive dependency exists.


>
> NOTE: the coverage of this script is NOT 100%. Some manual inspection
> and fixes are still required.
>
> Pass 1 treats all 817 packages. After a quick glance, all appears OK,
> but a more thorough analysis must be conducted.

  The script looks correct to me - not much can go wrong here.

>
> Pass 2 finds 67 packages that needs munging. There are a few packages
> left over, becasue they ahve constructs like
>      depends on PKG_FOO || PKG_BAR

  Can be skipped :-)

>
> Pass 3 finds 401 packages that 'select' packages without a corresponding
> 'depends on' on the _AVAILABLE symbol. A casual glance found that pass
> to be pretty OK, although a complete analysis has not ben done so far.

  I've updated the script with my own feedback; it's attached.

  Now only 279 packages are munged in the first pass, and only 146 in the third
pass.  However, the third pass detects about twenty of packages with inconsistent
select/depends (e.g. automake selects microperl, but microperl depends on MMU).
These should be fixed first, of course!

  I haven't had time to test it though.


  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pkg-avail
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120830/bdb75552/attachment.ksh>

[Buildroot] libffi or the crazy world of toolchain options

[Yann E. MORIN]

Arnout, Thomas, All,

On Thursday 30 August 2012 23:38:39 Arnout Vandecappelle wrote:
> On 08/30/12 00:53, Yann E. MORIN wrote:
> > 1) - introduces a BR2_PACKAGE_XXX_AVAILABLE symbol
> >     - moves all the package dependencies to this symbol
> >     - has the package depends only on this symbol

>   So that means the XXX_AVAILABLE is there even if the package has no
> dependencies? I'm not sure I like that... It means the simplest packages
> become more complex (only to make a few complex cases simpler).
> A patch with a shortstat that adds 4500+ lines, that can't be right :-)

Well, the script can be made to split the changes into small chunks.
Locally, I use 32 packages by patch. That's highly manageable. And pass-1
does not change anything in the actual dependency computation, except they
are moved one symbol up.

>   Take the example of transmission: the size of its Config.in doubles, but
> the real dependency is IPV6.  Adding all those "depends on ..._AVAILABLE"
> which are always true only hide the real restriction here.

In the begining, I thought like you. But I went to change all packages:
  - this way, all packages follow the exact same mechanism
  - updating packages dependencies is easy, because we do not have to
    chase down other packages that would then break
  - also, the dependency of the 'comment' is automatically updated (but
    that's minor, as it is in the same file, and still requires the user
    update the comment
  - adding the _AVAILABLE for new packages is not much trouble [*]

[*] I am also writing a small script that will partially automate the
addition of a new package by asking a few questions to the user, then
creating the skeleton files for that package. I hope to be able to post
this script soon...

>   So I propose to remove the _AVAILABLE symbols for packages that don't
> have actual dependencies.  At the moment, those are easy to find because
> the dependencies are present directly in the package (but of course the
> intention is to remove those direct dependencies if they're actually due to
> an indirect dependency).

And that will anyway require manual intervention. No script, brilliant as it
may be, would be able to do that. Too bad... :-]

> => In pass 1, only create the _AVAILABLE symbol if there is a depends on.
> Also log in a file for which packages the _AVAILABLE was created
> 
> => in pass 2 and 3, only execute the transformation if the _AVAILABLE
> exists.
> 
> 
>   Note that the disadvantage of restricting the _AVAILABLE to packages
> that really need it, is that there's more work when a package acquires its first
> toolchain dependency. Indeed, you have to add the _AVAILABLE symbol,
> and look for all packages that select this one and add an _AVAILABLE
> dependency. However, I think it doesn't often occur that a package
> acquires a new (toolchain) dependency, and when it does it usually already
> has an existing dependency (cfr. libglib2, python, xorg7, efl).  So, even
> the libffi case wouldn't have cost much effort.

Looking at how Thomas' libffi patchset is big, I doubt it was effortless! ;-)

> > 2) - transforms all 'depends on BR2_PACKAGE_XXX' into a dependency
> >       on the corresponding _AVAILABLE symbol
> >     - adds a select on the corresponding package
>   Actually I don't think we want this step.  The "depends on BR2_PACKAGE_XXX"
> construct is used to hide packages that depend on a super-feature, like
> X11 or python. In other cases, it's used to reduce the size of the menus where
> relevant; e.g. dbus-glib is only relevant if you have dbus. This isn't perfectly
> clear-cut,

As a user, I do not care about "super-features". What I care is that the package
I want be:
  - either visible, and selects whatever it requires;
  - or hidden, and a comment tells me why it is not visible (aka. not
    available) so I can take action to remedy the situation.

As for the size of the menus, I don't see one or a few packages hidden
making a big deifference (eg. in the "Networking Applications" sub-menu).
My opinion, of course! ;-)

> but it shouldn't be done mechanically.

That's why I said: "Some manual inspection and fixes are still required."

> > 3) - checks and fixes 'select BR2_PACKAGE_XXX' that does not have a
> >       corresponding 'depends on BR2_PACKAGE_XXX_AVAILABLE'
> 
>   What is missing as a fourth step is the removal of the dependencies which are
> actually due to transitive dependencies. They can be detected because normally
> we write
> depends on BR2_USE_WCHAR # glib2
> in such a situation.

What about this situation (first package by alphabetical order!):

    config BR2_PACKAGE_ACL
        bool "acl"
        select BR2_PACKAGE_ATTR
        depends on BR2_LARGEFILE

    config BR2_PACKAGE_ATTR
        bool "attr"
        depends on BR2_LARGEFILE

Does acl really require LARGEFILE for itself, or because it requires attr
which itself requires LARGEFILE?

So, transitive dependencies are not systematically identified, so they are
not easy to automatically remove in a fourth step, as you suggest.

Yes, for those that *are* identified, I was already planning this fourth
step, but, hey, human beings have a lot of physical requirements: food,
drink, sleep, and so on! Hehe! ;-)

> But again, I wouldn't do this mechanically. There are only
> 85 of these comments, and you have the "depends on ..._AVAILABLE" below
> to verify if the transitive dependency exists.
> 
> 
> >
> > NOTE: the coverage of this script is NOT 100%. Some manual inspection
> > and fixes are still required.
> >
> > Pass 1 treats all 817 packages. After a quick glance, all appears OK,
> > but a more thorough analysis must be conducted.
> 
>   The script looks correct to me - not much can go wrong here.

Believe me, things *can* go wrong! I had a few issues with the first
iterations of the script, because of weird dendencies (deps on XXX||FOO).

> > Pass 2 finds 67 packages that needs munging. There are a few packages
> > left over, becasue they ahve constructs like
> >      depends on PKG_FOO || PKG_BAR
> 
>   Can be skipped :-)

You mean pass-2, or the weird constructs?

> > Pass 3 finds 401 packages that 'select' packages without a corresponding
> > 'depends on' on the _AVAILABLE symbol. A casual glance found that pass
> > to be pretty OK, although a complete analysis has not ben done so far.
> 
>   I've updated the script with my own feedback; it's attached.

Thank you! I'll have a look tomorrow.

>   Now only 279 packages are munged in the first pass, and only 146 in the third
> pass.  However, the third pass detects about twenty of packages with inconsistent
> select/depends (e.g. automake selects microperl, but microperl depends on MMU).
> These should be fixed first, of course!

Well, that's the whole point of adding the _AVAILABLE stuff...
Or did I miss something?...

Thanks for the review!

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

[Buildroot] libffi or the crazy world of toolchain options

[Arnout Vandecappelle]

On 08/31/12 00:35, Yann E. MORIN wrote:
> Arnout, Thomas, All,
>
> On Thursday 30 August 2012 23:38:39 Arnout Vandecappelle wrote:
> > On 08/30/12 00:53, Yann E. MORIN wrote:
> >> 1) - introduces a BR2_PACKAGE_XXX_AVAILABLE symbol
> >>      - moves all the package dependencies to this symbol
> >>      - has the package depends only on this symbol
>
> >    So that means the XXX_AVAILABLE is there even if the package has no
> > dependencies? I'm not sure I like that... It means the simplest packages
> > become more complex (only to make a few complex cases simpler).
> > A patch with a shortstat that adds 4500+ lines, that can't be right :-)
>
> Well, the script can be made to split the changes into small chunks.
> Locally, I use 32 packages by patch. That's highly manageable. And pass-1
> does not change anything in the actual dependency computation, except they
> are moved one symbol up.

  Ah yes, forgot to mention that: I don't think it makes sense to split the patch
into smaller patches per 32 packages.  It's still the complete patch that needs
to be reviewed.

  It _does_ make a lot of sense to split it per pass.

>
> >    Take the example of transmission: the size of its Config.in doubles, but
> > the real dependency is IPV6.  Adding all those "depends on ..._AVAILABLE"
> > which are always true only hide the real restriction here.
>
> In the begining, I thought like you. But I went to change all packages:
>    - this way, all packages follow the exact same mechanism
  Good point.

>    - updating packages dependencies is easy, because we do not have to
>      chase down other packages that would then break
  My point is that it is still easy.  I don't think we have had any case in the last
two years where it would require more than 15 lines of diffstat.  See libffi,
below.

>    - also, the dependency of the 'comment' is automatically updated (but
>      that's minor, as it is in the same file, and still requires the user
>      update the comment
  Good point.

>    - adding the _AVAILABLE for new packages is not much trouble [*]
>
> [*] I am also writing a small script that will partially automate the
> addition of a new package by asking a few questions to the user, then
> creating the skeleton files for that package. I hope to be able to post
> this script soon...
  Then it could indeed be more affordable.

>
> >    So I propose to remove the _AVAILABLE symbols for packages that don't
> > have actual dependencies.  At the moment, those are easy to find because
> > the dependencies are present directly in the package (but of course the
> > intention is to remove those direct dependencies if they're actually due to
> > an indirect dependency).
>
> And that will anyway require manual intervention. No script, brilliant as it
> may be, would be able to do that. Too bad... :-]
  Ack.

>
> > =>  In pass 1, only create the _AVAILABLE symbol if there is a depends on.
> > Also log in a file for which packages the _AVAILABLE was created
> >
> > =>  in pass 2 and 3, only execute the transformation if the _AVAILABLE
> > exists.
> >
> >
> >    Note that the disadvantage of restricting the _AVAILABLE to packages
> > that really need it, is that there's more work when a package acquires its first
> > toolchain dependency. Indeed, you have to add the _AVAILABLE symbol,
> > and look for all packages that select this one and add an _AVAILABLE
> > dependency. However, I think it doesn't often occur that a package
> > acquires a new (toolchain) dependency, and when it does it usually already
> > has an existing dependency (cfr. libglib2, python, xorg7, efl).  So, even
> > the libffi case wouldn't have cost much effort.
>
> Looking at how Thomas' libffi patchset is big, I doubt it was effortless! ;-)
  My point is: after this change (the introduction of the _AVAILABLE symbol
is still brilliant!) the libffi patch would just be roughly 15 lines.  You would have
to introduce the _AVAILABLE symbol for libffi, and add it to the two packages
that depend on libffi: libglib2 and python. Since both of them already have an
_AVAILABLE symbol, the recursion stops there.

  The reason is that the tricky packages (libglib2, python, x11r7, efl) already have
a toolchain dependency, so they will have an _AVAILABLE symbol.
>
> >> 2) - transforms all 'depends on BR2_PACKAGE_XXX' into a dependency
> >>        on the corresponding _AVAILABLE symbol
> >>      - adds a select on the corresponding package
> >    Actually I don't think we want this step.  The "depends on BR2_PACKAGE_XXX"
> > construct is used to hide packages that depend on a super-feature, like
> > X11 or python. In other cases, it's used to reduce the size of the menus where
> > relevant; e.g. dbus-glib is only relevant if you have dbus. This isn't perfectly
> > clear-cut,
>
> As a user, I do not care about "super-features". What I care is that the package
> I want be:
>    - either visible, and selects whatever it requires;
>    - or hidden, and a comment tells me why it is not visible (aka. not
>      available) so I can take action to remedy the situation.
>
> As for the size of the menus, I don't see one or a few packages hidden
> making a big deifference (eg. in the "Networking Applications" sub-menu).
> My opinion, of course! ;-)
  You may be right, but that's an independent issue.
>
> > but it shouldn't be done mechanically.
>
> That's why I said: "Some manual inspection and fixes are still required."
>
> >> 3) - checks and fixes 'select BR2_PACKAGE_XXX' that does not have a
> >>        corresponding 'depends on BR2_PACKAGE_XXX_AVAILABLE'
> >
> >    What is missing as a fourth step is the removal of the dependencies which are
> > actually due to transitive dependencies. They can be detected because normally
> > we write
> > depends on BR2_USE_WCHAR # glib2
> > in such a situation.
>
> What about this situation (first package by alphabetical order!):
>
>      config BR2_PACKAGE_ACL
>          bool "acl"
>          select BR2_PACKAGE_ATTR
>          depends on BR2_LARGEFILE
>
>      config BR2_PACKAGE_ATTR
>          bool "attr"
>          depends on BR2_LARGEFILE
>
> Does acl really require LARGEFILE for itself, or because it requires attr
> which itself requires LARGEFILE?
  There you can't say off-hand, so either you check it manually or leave the redundant
dependency.  However, in the cases where there is a comment, it can be removed.
>
> So, transitive dependencies are not systematically identified, so they are
> not easy to automatically remove in a fourth step, as you suggest.
>
> Yes, for those that *are* identified, I was already planning this fourth
> step, but, hey, human beings have a lot of physical requirements: food,
> drink, sleep, and so on! Hehe! ;-)
>
> > But again, I wouldn't do this mechanically. There are only
> > 85 of these comments, and you have the "depends on ..._AVAILABLE" below
> > to verify if the transitive dependency exists.
  As I said, because there are only 85 of the easy ones, and replacing manually
is easy, I'd do it manually.
> >
> >
> >>
> >> NOTE: the coverage of this script is NOT 100%. Some manual inspection
> >> and fixes are still required.
> >>
> >> Pass 1 treats all 817 packages. After a quick glance, all appears OK,
> >> but a more thorough analysis must be conducted.
> >
> >    The script looks correct to me - not much can go wrong here.
>
> Believe me, things *can* go wrong! I had a few issues with the first
> iterations of the script, because of weird dendencies (deps on XXX||FOO).
>
> >> Pass 2 finds 67 packages that needs munging. There are a few packages
> >> left over, becasue they ahve constructs like
> >>       depends on PKG_FOO || PKG_BAR
> >
> >    Can be skipped :-)
>
> You mean pass-2, or the weird constructs?
>
> >> Pass 3 finds 401 packages that 'select' packages without a corresponding
> >> 'depends on' on the _AVAILABLE symbol. A casual glance found that pass
> >> to be pretty OK, although a complete analysis has not ben done so far.
> >
> >    I've updated the script with my own feedback; it's attached.
>
> Thank you! I'll have a look tomorrow.
>
> >    Now only 279 packages are munged in the first pass, and only 146 in the third
> > pass.  However, the third pass detects about twenty of packages with inconsistent
> > select/depends (e.g. automake selects microperl, but microperl depends on MMU).
> > These should be fixed first, of course!
>
> Well, that's the whole point of adding the _AVAILABLE stuff...
  Couldn't agree more!
> Or did I miss something?...
>
> Thanks for the review!
>
> Regards,
> Yann E. MORIN.
>

  Regards,
  Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] libffi or the crazy world of toolchain options

[Yann E. MORIN]

Arnout, Thomas, All,

On Friday 31 August 2012 10:28:32 Arnout Vandecappelle wrote:
>   Ah yes, forgot to mention that: I don't think it makes sense to split the patch
> into smaller patches per 32 packages.  It's still the complete patch that needs
> to be reviewed.

Well, it's at least easier for me to check that my^Wour script does not
act too sutpid! ;-)

Nothing prevents us from squashing all related cset together before
submission for upstreaming.

>   It _does_ make a lot of sense to split it per pass.

That's for sure, yes.

>   My point is: after this change (the introduction of the _AVAILABLE symbol
> is still brilliant!) the libffi patch would just be roughly 15 lines.  You would have
> to introduce the _AVAILABLE symbol for libffi, and add it to the two packages
> that depend on libffi: libglib2 and python. Since both of them already have an
> _AVAILABLE symbol, the recursion stops there.

OK, I missunderstood your original mail. Ack.

>   The reason is that the tricky packages (libglib2, python, x11r7, efl) already have
> a toolchain dependency, so they will have an _AVAILABLE symbol.

Now I understand that you speak about _after_ the introduction of _AVAILABLE.
Pfeew... Takes time to get into my little head! ;-)

> > Does acl really require LARGEFILE for itself, or because it requires attr
> > which itself requires LARGEFILE?
>   There you can't say off-hand, so either you check it manually or leave the redundant
> dependency.

Better safe than sorry: I'd leave it. Any one adventurous enough could
test later.

> However, in the cases where there is a comment, it can be removed.

Yep.

>   As I said, because there are only 85 of the easy ones, and replacing manually
> is easy, I'd do it manually.

Gah. Any repetitive task of which there are more than a few instances, I
tend to automate. At least, for two reasons:
  - there is a script that gets committed with the change, so we can later
    see what was done, and can reproduce again later should a similar case
    appears again,
  - I really abhor repetitive tasks, and I realy like automating stuff! ;-]

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