When a package A depends on config option B and toolchain option C, then
the comment that is given when C is not fulfilled should also depend on B.
For example:
config BR2_PACKAGE_A
depends on BR2_B
depends on BR2_LARGEFILE
depends on BR2_WCHAR
comment "A needs a toolchain w/ largefile, wchar"
depends on !BR2_LARGEFILE || !BR2_WCHAR
This comment should actually be:
comment "A needs a toolchain w/ largefile, wchar"
depends on BR2_B
depends on !BR2_LARGEFILE || !BR2_WCHAR
or if possible (typically when B is a package config option declared in that
same Config.in file):
if BR2_B
comment "A needs a toolchain w/ largefile, wchar"
depends on !BR2_LARGEFILE || !BR2_WCHAR
[other config options depending on B]
endif
Otherwise, the comment would be visible even though the other dependencies
are not met.
This patch adds such missing dependencies, and changes existing such
dependencies from
depends on BR2_BASE_DEP && !BR2_TOOLCHAIN_USES_GLIBC
to
depends on BR2_BASE_DEP
depends on !BR2_TOOLCHAIN_USES_GLIBC
so that (positive) base dependencies are separate from the (negative)
toolchain dependencies. This strategy makes it easier to write such comments
(because one can simply copy the base dependency from the actual package
config option), but also avoids complex and long boolean expressions.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(untested)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch lines up the comments in Config.in files that clarify which
toolchain options the package depends on.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds a dependency of the libglib2 package on thread
support in the toolchain, since upstream libglib2 doesn't build
without thread support. The commit is rather large as it involves
propagating the dependency on thread support to all reverse
dependencies of the libglib2 package.
[Thomas: squash all patches into one, make a few minor fixes, the most
important one being to not add comments about MMU requirement when a
package doesn't work on !MMU platforms.]
Signed-off-by: Spenser Gilliland <spenser@gillilanding.com>
* Drop DirectFB support from libgtk2
* bump libgtk2 to version 2.24.18
[Peter: fixup patch whitespace changes]
Signed-off-by: Spenser Gilliland <spenser@gillilanding.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
libgtk2 is a X client library, so it doesn't make sense for it to
depend on the X.org server. Instead, it should depend on the X client
libraries.
This patch therefore replaces the dependency on the X server by a
dependency on libX11, libXext, libXrender and fontconfig, that are the
mandatory requirements to build the X backend of Gtk.
[Peter: don't add an empty line before gtk demo help text]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Finally, we bump Gtk from the old and ancient 2.12 version to the
latest 2.22.0 version currently available.
The DirectFB support is Gtk 2.22 compiles again thanks to the work of
Lionel Landwerlin (it was broken in every Gtk version between 2.12 and
2.20). Therefore, Gtk on DirectFB is no longer marked as deprecated.
In addition to this, we :
* Upgrade the "reduce-dependencies" patch
* Remove the "configure" and "no-tests" patches which do not seem to
be useful anymore
* Add a libtool patch
We also remove references to a non-existant 2.15 gtk version in
libgtk2.mk.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Pango was recently updated to v1.28 as a dependency of webkit, but its
freetype support has unfortunately been rewritten with parts in C++
(since pango 1.25), so adjust dependencies of pango and users of it to
require C++ support.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
libgtk2 on DirectFB is deprecated because it is no longer supported in
recent versions of Gtk. We will remove support for Gtk over DirectFB
in the next Buildroot version unless support for DirectFB in mainline
Gtk is improved in the mean time.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
gettext needs WCHAR support in the toolchain, and as libglib2 depends on
gettext and lots of stuff depends on libglib2, quite a lot of packages
needs to have their dependencies adjusted.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Many packages used to depend on BR2_PACKAGE_XORG||BR2_PACKAGE_XORG7,
but this is useless since BR2_PACKAGE_XORG is a non-existing
configuration option. So, these depencies gets simplified to
BR2_PACKAGE_XORG7 only.
Some others were depending on BR2_PACKAGE_TINYX (which doesn't) exist
or BR2_PACKAGE_XSERVER_xorg || BR2_PACKAGE_XSERVER_tiny ||
BR2_PACKAGE_XSERVER_x11r7. Replace all that mess by a simple
dependency on BR2_PACKAGE_XORG7.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The host versions shouldn't be visible in Kconfig, so remove the
reference to BR2_PACKAGE_PKGCONFIG everywhere and prefix the host targets
with host-.
At the same time add pkgconfig for the target (E.G. for development) and
let BR2_PACKAGE_PKGCONFIG control that package.
Notice: all defconfigs in the tree have been updated, but make sure to
disable the pkgconfig package (unless you want it) if you use an external
config, otherwise you'll end up with pkgconfig and glib2 in the target.
Should be no different for X builds.
Config.in | 3 +--
libgtk2.mk | 7 +++----
2 files changed, 4 insertions(+), 6 deletions(-)
Signed-off-by: daniel.j.laird@nxp.com
package/libgtk2/Config.in
Allow DirectFB to turn on LIBGTK2 support without X being enabled.
Disable autoselection of cups. May not be wanted (Can cause crosscompilation issues).
package/libgtk2/libgtk2.mk
Remove unnessary redefine of PKG_CONFIG_*
Pass $(DISABLE_LARGEFILE) to configure (supports large file or not)
Move 'cups' to X extra dependencies instead of general.
quite work yet for me, but this clearly is a huge project and not having it
quite work on the first pass is hardly unexpected. We definately want this
stuff in buildroot.
