* [Buildroot] libffi or the crazy world of toolchain options @ 2012-08-25 15:06 Thomas Petazzoni 2012-08-25 15:06 ` [Buildroot] [PATCH] Adjust dependencies so that libffi is not used on unsupported systems Thomas Petazzoni 2012-08-26 10:23 ` [Buildroot] libffi or the crazy world of toolchain options Yann E. MORIN 0 siblings, 2 replies; 12+ messages in thread From: Thomas Petazzoni @ 2012-08-25 15:06 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [PATCH] Adjust dependencies so that libffi is not used on unsupported systems 2012-08-25 15:06 [Buildroot] libffi or the crazy world of toolchain options Thomas Petazzoni @ 2012-08-25 15:06 ` Thomas Petazzoni 2012-08-26 10:23 ` [Buildroot] libffi or the crazy world of toolchain options Yann E. MORIN 1 sibling, 0 replies; 12+ messages in thread From: Thomas Petazzoni @ 2012-08-25 15:06 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [Buildroot] libffi or the crazy world of toolchain options 2012-08-25 15:06 [Buildroot] libffi or the crazy world of toolchain options Thomas Petazzoni 2012-08-25 15:06 ` [Buildroot] [PATCH] Adjust dependencies so that libffi is not used on unsupported systems Thomas Petazzoni @ 2012-08-26 10:23 ` Yann E. MORIN 2012-08-26 20:40 ` Yann E. MORIN 2012-08-27 18:29 ` Thomas Petazzoni 1 sibling, 2 replies; 12+ messages in thread From: Yann E. MORIN @ 2012-08-26 10:23 UTC (permalink / raw) To: buildroot 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] libffi or the crazy world of toolchain options 2012-08-26 10:23 ` [Buildroot] libffi or the crazy world of toolchain options Yann E. MORIN @ 2012-08-26 20:40 ` Yann E. MORIN 2012-08-26 22:43 ` Yann E. MORIN 2012-08-29 22:53 ` Yann E. MORIN 2012-08-27 18:29 ` Thomas Petazzoni 1 sibling, 2 replies; 12+ messages in thread From: Yann E. MORIN @ 2012-08-26 20:40 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] libffi or the crazy world of toolchain options 2012-08-26 20:40 ` Yann E. MORIN @ 2012-08-26 22:43 ` Yann E. MORIN 2012-08-28 17:14 ` Yann E. MORIN 2012-08-29 22:53 ` Yann E. MORIN 1 sibling, 1 reply; 12+ messages in thread From: Yann E. MORIN @ 2012-08-26 22:43 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] libffi or the crazy world of toolchain options 2012-08-26 22:43 ` Yann E. MORIN @ 2012-08-28 17:14 ` Yann E. MORIN 0 siblings, 0 replies; 12+ messages in thread From: Yann E. MORIN @ 2012-08-28 17:14 UTC (permalink / raw) To: buildroot 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] libffi or the crazy world of toolchain options 2012-08-26 20:40 ` Yann E. MORIN 2012-08-26 22:43 ` Yann E. MORIN @ 2012-08-29 22:53 ` Yann E. MORIN 2012-08-30 21:38 ` Arnout Vandecappelle 1 sibling, 1 reply; 12+ messages in thread From: Yann E. MORIN @ 2012-08-29 22:53 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] libffi or the crazy world of toolchain options 2012-08-29 22:53 ` Yann E. MORIN @ 2012-08-30 21:38 ` Arnout Vandecappelle 2012-08-30 22:35 ` Yann E. MORIN 0 siblings, 1 reply; 12+ messages in thread From: Arnout Vandecappelle @ 2012-08-30 21:38 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] libffi or the crazy world of toolchain options 2012-08-30 21:38 ` Arnout Vandecappelle @ 2012-08-30 22:35 ` Yann E. MORIN 2012-08-31 8:28 ` Arnout Vandecappelle 0 siblings, 1 reply; 12+ messages in thread From: Yann E. MORIN @ 2012-08-30 22:35 UTC (permalink / raw) To: buildroot 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] libffi or the crazy world of toolchain options 2012-08-30 22:35 ` Yann E. MORIN @ 2012-08-31 8:28 ` Arnout Vandecappelle 2012-08-31 22:13 ` Yann E. MORIN 0 siblings, 1 reply; 12+ messages in thread From: Arnout Vandecappelle @ 2012-08-31 8:28 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] libffi or the crazy world of toolchain options 2012-08-31 8:28 ` Arnout Vandecappelle @ 2012-08-31 22:13 ` Yann E. MORIN 0 siblings, 0 replies; 12+ messages in thread From: Yann E. MORIN @ 2012-08-31 22:13 UTC (permalink / raw) To: buildroot 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] libffi or the crazy world of toolchain options 2012-08-26 10:23 ` [Buildroot] libffi or the crazy world of toolchain options Yann E. MORIN 2012-08-26 20:40 ` Yann E. MORIN @ 2012-08-27 18:29 ` Thomas Petazzoni 1 sibling, 0 replies; 12+ messages in thread From: Thomas Petazzoni @ 2012-08-27 18:29 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-08-31 22:13 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-08-25 15:06 [Buildroot] libffi or the crazy world of toolchain options Thomas Petazzoni 2012-08-25 15:06 ` [Buildroot] [PATCH] Adjust dependencies so that libffi is not used on unsupported systems Thomas Petazzoni 2012-08-26 10:23 ` [Buildroot] libffi or the crazy world of toolchain options Yann E. MORIN 2012-08-26 20:40 ` Yann E. MORIN 2012-08-26 22:43 ` Yann E. MORIN 2012-08-28 17:14 ` Yann E. MORIN 2012-08-29 22:53 ` Yann E. MORIN 2012-08-30 21:38 ` Arnout Vandecappelle 2012-08-30 22:35 ` Yann E. MORIN 2012-08-31 8:28 ` Arnout Vandecappelle 2012-08-31 22:13 ` Yann E. MORIN 2012-08-27 18:29 ` Thomas Petazzoni
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox