buildroot/package/opencv, branch 2016.02

cairo, harfbuzz: rework atomic dependencies

2016-02-06T10:16:00+00:00

This commit handles the reverse dependency tree of cairo in terms of atomic dependencies. There are two main changes: - cairo in fact no longer needs atomic operations. It can perfectly build without any __sync built-in, as was tested using an ARC toolchain without atomics, and a SPARC toolchain. Optionally, Cairo can use the __atomic builtins provided by gcc >= 4.7, so support for this is added as well. Thanks to this change, the BR2_ARCH_HAS_ATOMICS dependency is removed from cairo and all its reverse dependencies. - harfbuzz does require the __sync built-in for 4 bytes integers, so we add a dependency on BR2_TOOLCHAIN_HAS_SYNC_4 to harfbuzz and all its reverse dependency, the main one being the pango package. Due to this, the vast majority of gtk-related packages are moved to a dependency on BR2_ARCH_HAS_ATOMICS (which used to be due to cairo) to a dependency on BR2_TOOLCHAIN_HAS_SYNC_4 (due to pango -> harfbuzz). In detail: - cairo Remove BR2_ARCH_HAS_ATOMICS dependency, link against -latomic when gcc >= 4.8 in order to use the __atomic functions. - harfbuzz Add dependency on BR2_TOOLCHAIN_HAS_SYNC_4 - cairomm, gst-plugins-good, gst1-plugins-good, libgdiplus, libsvg-cairo, weston Remove BR2_ARCH_HAS_ATOMICS dependency (since cairo no longer needs atomics) - enlightenment, cwiid, gst-plugins-bad, gst-plugins-base, gst1-plugins-bad, gst1-plugins-base, gtkmm3, libevas-generic-loaders, libfm, libgail, libgtk2, libgtk3, librsvg, openbox, opencv, opencv3, pango, pangomm, pcmanfm, pinentry, rrdtool, webkit, webkitgtk24, xscreensaver Switch from a BR2_ARCH_HAS_ATOMICS dependency to a BR2_TOOLCHAIN_HAS_SYNC_4 (they depend on pango, harfbuzz, gtk, or some other related package) - directfb Remove BR2_ARCH_ATOMICS dependency of the BR2_PACKAGE_DIRECTFB_SVG (since cairo can build without atomics), but add a BR2_TOOLCHAIN_HAS_SYNC_4 dependency on BR2_PACKAGE_DIRECTFB itself since it does use __sync built-ins. This replaces the !BR2_sparc dependency. Signed-off-by: Thomas Petazzoni

opencv: use the same logic as opencv3 for gstreamer support

2015-11-28T22:04:42+00:00

The logic for enabling gstreamer support in opencv is not correct. We select gstreamer-0.10 packages but then we enable gstreamer1 support in the opencv.mk file. opencv3 has the correct logic, so let's use it in opencv as well. Fixes: http://autobuild.buildroot.net/results/f6d/f6d0a4ffe347cbb868998856aca674ba8bc2e281/ Signed-off-by: Vicente Olivert Riera Signed-off-by: Peter Korsgaard

ffmpeg: mark as not available on nios2

2015-11-11T14:55:07+00:00

ffmpeg was already marked as not available for the NIOS2 Sourcery toolchains, but it could still be built with the internal toolchain backend or a custom external toolchain. However, an inspection of the latest glibc source code indicates that FE_INVALID, FE_OVERFLOW and FE_UNDERFLOW and indeed not available in the nios2 variant of . Consequently, this patch makes ffmpeg not available on nios2, which allows to simplify a bit the dependencies. It propagates this dependency to: - minidlna (and at the same time makes sure the minidlna comment is not displayed on nios2, which wasn't properly taken into account until now) - mpd - opencv - opencv3 - squeezelite - tovid Even if it selects ffmpeg, Kodi does not need an update since Kodi is only available on a limited number of architectures (which don't include nios2, obviously). Other packages only make use of ffmpeg when available. Fixes: http://autobuild.buildroot.org/results/921/9212f5a6432c5e695ac0630695405cea05e28610/ Signed-off-by: Thomas Petazzoni

package/opencv: re-introduce opencv for opencv-2.4

2015-08-25T09:56:57+00:00

As Jonathan noticed in [1], users' applications may depend on opencv-2.4 APIs removed in opencv-3.0. So, re-introduce opencv package as it was right before the bump to opencv-3.0 (i.e.: commit bf00b5a9ea1ab4189fe5c7dea05f40d0bbbf2082). We do not support both OpenCV-2.4 and OpenCV-3 at the same time, so make OpenCV-3 depend on !OpenCV-2.4. [1] http://lists.busybox.net/pipermail/buildroot/2015-August/135270.html Cc: Jonathan Ben Avraham Cc: Thomas Petazzoni Signed-off-by: Samuel Martin [yann.morin.1998@free.fr: - remove legacy symbols, now - make opencv3 depends on !opencv, not the other way around - slitghly reword the commit log (opencv/opencv3 dependency) ] Signed-off-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

package: rename opencv -> opencv3

2015-08-25T09:51:35+00:00

Since there is a couple of API breaks between OpenCV 2.4 and 3.0, two distinct packages mutually exclusive will be integrated in the package tree. So, this change prepares the re-introduction of the OpenCV-2.4 package by renaming the current opencv package (which provides OpenCV-3.0) to opencv3. Reverse dependencies (vlc) is fixed to use the new symbols. Cc: Jonathan Ben Avraham Cc: Thomas Petazzoni Signed-off-by: Samuel Martin [yann.morin.1998@free.fr: - fix missed usage in vlc.mk - don't remove legacy OpenCV symbols - fix 'endif' comment - slightly reword commit log (reverse deps) ] Signed-off-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

opencv: mark as not available on Xtensa

2015-08-08T15:16:19+00:00

OpenCV currently does not build on Xtensa due to compiler/assembler issues: Error: operand 2 of 'l32r' has out of range value '4294632228' Until this gets fixed, let's disable OpenCV on Xtensa. Temporarily works around: http://autobuild.buildroot.net/results/0be/0bed0779685d9ed83466a4d29a0281ca93043a2e/ Signed-off-by: Thomas Petazzoni

package/opencv: add opengl support

2015-07-06T09:50:00+00:00

In OpenCV, OpenGL is only used by highgui module. OpenGL support is done using extensions from 3rd party framework: either Qt5OpenGL with Qt5 (with GL support only, not GLES); or gtkglext (which is not available in Buildroot) with gtk2 So, make OpenGL knob a sub-option of the Qt5 support option. Note: we enclose both the GUI toolkit choice and the GL option in an if-block, so that the GL option gets properly indented; having it depend on WITH_QT5 is not enough, because it does not directly follow it, so kconfig would not consider it for indenting. Signed-off-by: Samuel Martin [yann.morin.1998@free.fr: tweak commit log about the if-block] Reviewed-by: "Yann E. MORIN" Signed-off-by: Yann E. MORIN Signed-off-by: Thomas Petazzoni

package/opencv: add gtk3 support

2015-07-06T09:50:00+00:00

OpenCV now also supports gtk3 as a GUI toolkit, in addition to gtk2, but only one may be enabled at a time. So, add gtk3 in the choice to select the GUI toolkit. Signed-off-by: Samuel Martin [yann.morin.1998@free.fr: drop the superfluous depends-on for the kconfig symbol, since they're no longer needed now we depend-on rather than select] Signed-off-by: Yann E. MORIN Signed-off-by: Thomas Petazzoni

package/opencv: add qt5 support

2015-07-06T09:50:00+00:00

Starting with the 2.4.6 release, OpenCV supports either Qt4 or Qt5 as GUI toolkit, so add Qt5 in the GUI toolkit choice. When Qt4 is enabled (and thus Qt5 is hidden and disabled), no need to show a comment stating "Qt5 support needs Qt5", because Qt5 is not selectable. Conversely, when Qt5 is enabled and Qt4 is not, then no need to show a comment stating "Qt4 support needs Qt4", because enabling Qt4 would disable Qt5. So, we only show the comments when neither toolkit is enabled. Signed-off-by: Samuel Martin Cc: "Yann E. MORIN" [yann.morin.1998@free.fr: split-out the Qt5 hunk from the switch-selects-to-depends hunk] Signed-off-by: Yann E. MORIN Signed-off-by: Thomas Petazzoni

package/opencv: depends on GUI toolkits, rather than select them

2015-07-06T09:50:00+00:00

Currently, we only support either Qt4 or gtk2, but OpenCV also additionally supports Qt5 or gtk3, making for a choice of four toolkits, one of: Qt4, Qt5, gtk3, gtk2 (and obviously, none). Since Buildroot does not support coexistence of Qt4 and Qt5, we can no longer select one and depend on the other, like so: config BR2_PKG_OCV_WITH_QT4 bool "Qt4" depends on !BR2_PKG_QT5 select BR2_PKG_QT config BR2_PKG_OCV_WITH_QT5 bool "Qt5" depends on !BR2_PKG_QT select BR2_PKG_QT5 otherwise, we'd get a circular dependency chain in Kconfig, which would complain with: package/opencv/Config.in:57:error: recursive dependency detected! package/opencv/Config.in:57: choice contains symbol BR2_PKG_OCV_WITH_QT5 package/opencv/Config.in:111: symbol BR2_PKG_OCV_WITH_QT5 depends on BR2_PKG_QT package/qt/Config.in:5: symbol BR2_PKG_QT is selected by BR2_PKG_OCV_WITH_QT package/opencv/Config.in:98: symbol BR2_PKG_OCV_WITH_QT is part of choice Instead, we need to depend on either Qt version. So, to have a consistent choice, we make all support for GUI toolkits actually depend on the toolkit, rather than select it. Signed-off-by: Samuel Martin [yann.morin.1998@free.fr: split-out the switch-selects-to-depends hunk from the add-qt5 hunk] Signed-off-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni