[Buildroot] [PATCH 1/3] qt{4, 5}: add an explicit choice to express Buildroot does not support their coexistence

[Buildroot] [PATCH 1/3] qt{4, 5}: add an explicit choice to express Buildroot does not support their coexistence

[Samuel Martin]

Qt4 and Qt5 does not provide the same APIs; they can usually coexist on the
same system.
However, Buildroot does not alllow this coexistence because of some host-tools
(qmake, etc) troubles when building qmake-based packages or projects (inside
or outside Buildroot).

So, since it is not possible to consider making a virtual package because of
the APIs' differences, add an explicit choice.

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 package/Config.in     |  7 ++++++-
 package/Config.in.qt  | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 package/qt/Config.in  | 18 +++---------------
 package/qt5/Config.in | 21 ++++-----------------
 4 files changed, 59 insertions(+), 33 deletions(-)
 create mode 100644 package/Config.in.qt

diff --git a/package/Config.in b/package/Config.in
index 7c24dab..415f7f8 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -142,10 +142,12 @@ source "package/sdl_gfx/Config.in"
 
 comment "other GUIs"
 source "package/efl/Config.in"
-source "package/qt/Config.in"
+
+source "package/Config.in.qt"
 
 if BR2_PACKAGE_QT
 comment "QT libraries and helper libraries"
+source "package/qt/Config.in"
 source "package/grantlee/Config.in"
 source "package/qextserialport/Config.in"
 source "package/qjson/Config.in"
@@ -153,7 +155,10 @@ source "package/qtuio/Config.in"
 source "package/qwt/Config.in"
 endif
 
+if BR2_PACKAGE_QT5
 source "package/qt5/Config.in"
+endif
+
 source "package/x11r7/Config.in"
 source "package/weston/Config.in"
 
diff --git a/package/Config.in.qt b/package/Config.in.qt
new file mode 100644
index 0000000..a61bd81
--- /dev/null
+++ b/package/Config.in.qt
@@ -0,0 +1,46 @@
+choice
+	prompt "Qt library"
+	default BR2_PACKAGE_QT_NONE
+	help
+	  Qt4 and Qt5 provide different set of APIs, so they are not equivalent.
+	  They usually may coexist on the same system, but not in Buildroot because
+	  host-tools like qmake are not properly handled between those two
+	  versions.
+
+	  This host-tools issue cause troubles when building project using qmake.
+
+	  So, there is an explicit choice for what version of Qt should be build by
+	  Buildroot.
+
+config BR2_PACKAGE_QTNONE
+	bool "none"
+
+comment "Qt4 requires a toolchain with C++ support enabled"
+	depends on !BR2_INSTALL_LIBSTDCPP
+
+config BR2_PACKAGE_QT
+	bool "Qt4"
+	depends on !BR2_avr32 # lacks TLS
+	depends on BR2_INSTALL_LIBSTDCPP
+	help
+	  Qt is a cross-platform application and UI framework for
+	  developers using C++.
+
+	  http://qt-project.org
+
+comment "Qt5 needs a toolchain with WCHAR, IPv6, thread and C++ support"
+	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || !BR2_INET_IPV6 || !BR2_TOOLCHAIN_HAS_THREADS
+
+config BR2_PACKAGE_QT5
+	bool "Qt5"
+	depends on BR2_INSTALL_LIBSTDCPP
+	depends on BR2_USE_WCHAR
+	depends on BR2_INET_IPV6
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	help
+	  This option enables the Qt5 framework. Sub-options allow to
+	  select which modules should be built.
+
+	  http://qt-project.org
+
+endchoice
diff --git a/package/qt/Config.in b/package/qt/Config.in
index 9f6e54d..fe92838 100644
--- a/package/qt/Config.in
+++ b/package/qt/Config.in
@@ -1,17 +1,5 @@
-comment "qt requires a toolchain with C++ support enabled"
-	depends on !BR2_INSTALL_LIBSTDCPP
-
-menuconfig BR2_PACKAGE_QT
-	bool "Qt"
-	depends on !BR2_avr32 # lacks TLS
-	depends on BR2_INSTALL_LIBSTDCPP
-	help
-	  Qt is a cross-platform application and UI framework for
-	  developers using C++.
-
-	  http://qt-project.org
-
-if BR2_PACKAGE_QT
+menu "Qt4"
+	depends on BR2_PACKAGE_QT
 
 config BR2_PACKAGE_QT_DEBUG
 	bool "Compile with debug support"
@@ -392,4 +380,4 @@ config BR2_PACKAGE_QT_DECLARATIVE
 	  Build the Qt Declarative Module for qml support
 	  if unsure, say n.
 
-endif # BR2_PACKAGE_QT
+endmenu
diff --git a/package/qt5/Config.in b/package/qt5/Config.in
index 2945d96..fef988c 100644
--- a/package/qt5/Config.in
+++ b/package/qt5/Config.in
@@ -1,20 +1,6 @@
-comment "Qt5 needs a toolchain with WCHAR, IPv6, thread and C++ support"
-	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || !BR2_INET_IPV6 || !BR2_TOOLCHAIN_HAS_THREADS
+menu "Qt5"
+	depends on BR2_PACKAGE_QT5
 
-menuconfig BR2_PACKAGE_QT5
-	bool "Qt5"
-	depends on BR2_INSTALL_LIBSTDCPP
-	depends on BR2_USE_WCHAR
-	depends on BR2_INET_IPV6
-	depends on BR2_TOOLCHAIN_HAS_THREADS
-	depends on !BR2_PACKAGE_QT
-	help
-	  This option enables the Qt5 framework. Sub-options allow to
-	  select which modules should be built.
-
-	  http://qt-project.org
-
-if BR2_PACKAGE_QT5
 source "package/qt5/qt5base/Config.in"
 source "package/qt5/qt5declarative/Config.in"
 source "package/qt5/qt5graphicaleffects/Config.in"
@@ -26,4 +12,5 @@ source "package/qt5/qt5script/Config.in"
 source "package/qt5/qt5svg/Config.in"
 source "package/qt5/qt5webkit/Config.in"
 source "package/qt5/qt5xmlpatterns/Config.in"
-endif
+
+endmenu
-- 
1.8.3.2

[Buildroot] [PATCH 2/3] manual: add faq entry explaining why Buildroot does not support Qt{4, 5} coexistence

[Samuel Martin]

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 docs/manual/faq-troubleshooting.txt | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/docs/manual/faq-troubleshooting.txt b/docs/manual/faq-troubleshooting.txt
index f91a8ef..d190d26 100644
--- a/docs/manual/faq-troubleshooting.txt
+++ b/docs/manual/faq-troubleshooting.txt
@@ -126,3 +126,18 @@ directory as the new root, will most likely fail.
 If you want to run the target filesystem inside a chroot, or as an NFS
 root, then use the tarball image generated in +images/+ and extract it
 as root.
+
+[[faq-why-qt4-qt5-cannot-coexist]]
+Why Qt4 and Qt5 cannot coexist in Buildroot?
+--------------------------------------------
+
+Qt4 and Qt5 provide different set of APIs, so they are not equivalent.
+
+They usually may coexist on the same system, but not in Buildroot because
+host-tools like +qmake+ are not properly handled between those two versions.
+
+This host-tools issue cause troubles when building projects or packages
+using qmake (inside and outside Buildroot).
+
+Thus, there is an explicit choice for what version of Qt should be build by
+Buildroot.
-- 
1.8.3.2

[Buildroot] [PATCH 3/3] opencv: bump version to 2.4.6

[Samuel Martin]

Also:
- add license details;
- add new modules option;
- explicitly disable python support to avoid being confuse by the one from the
  host;
- update qt support (now handle qt4/qt5)

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 package/opencv/Config.in | 34 ++++++++++++++++++++++++++--------
 package/opencv/opencv.mk | 18 +++++++++++++-----
 2 files changed, 39 insertions(+), 13 deletions(-)

diff --git a/package/opencv/Config.in b/package/opencv/Config.in
index 26bf5e7..553a0a5 100644
--- a/package/opencv/Config.in
+++ b/package/opencv/Config.in
@@ -97,6 +97,13 @@ config BR2_PACKAGE_OPENCV_LIB_STITCHING
 	help
 	  Include opencv_stitching module into the OpenCV build.
 
+config BR2_PACKAGE_OPENCV_LIB_SUPERRES
+	bool "superres"
+	default y
+	help
+	  Include opencv_superres "super resolution" - module into the OpenCV
+	  build.
+
 config BR2_PACKAGE_OPENCV_LIB_TS
 	bool "ts (touchscreen)"
 	default y
@@ -164,15 +171,26 @@ config BR2_PACKAGE_OPENCV_WITH_PNG
 	help
 	  Use shared libpng from the target system.
 
+if BR2_INSTALL_LIBSTDCPP && (!BR2_avr32 || (BR2_USE_WCHAR && BR2_INET_IPV6 && BR2_TOOLCHAIN_HAS_THREADS)) # qt{4,5} dependencies
+
+if !BR2_PACKAGE_QT && !BR2_PACKAGE_QT5
+comment "Qt support not available."
+comment "Enable one of the Qt libraries before enabling Qt support in OpenCV"
+endif
+
 config BR2_PACKAGE_OPENCV_WITH_QT
-	bool "qt backend support"
-	depends on BR2_INSTALL_LIBSTDCPP
-	depends on !BR2_avr32 # qt
-	select BR2_PACKAGE_QT
-	select BR2_PACKAGE_QT_STL
-	default y
-	help
-	  Use Qt with STL support
+	bool "Qt support"
+	#prompt "Qt4 support" if BR2_PACKAGE_QT
+	#prompt "Qt5 support" if BR2_PACKAGE_QT5
+	depends on BR2_PACKAGE_QT || BR2_PACKAGE_QT5
+	select BR2_PACKAGE_QT_STL             if BR2_PACKAGE_QT
+	select BR2_PACKAGE_QT5BASE            if BR2_PACKAGE_QT5
+	select BR2_PACKAGE_QT5BASE_CONCURRENT if BR2_PACKAGE_QT5
+	select BR2_PACKAGE_QT5BASE_TEST       if BR2_PACKAGE_QT5
+	select BR2_PACKAGE_QT5BASE_GUI        if BR2_PACKAGE_QT5
+	select BR2_PACKAGE_QT5BASE_WIDGETS    if BR2_PACKAGE_QT5
+
+endif # qt{4,5} dependencies
 
 config BR2_PACKAGE_OPENCV_WITH_TIFF
 	bool "tiff support"
diff --git a/package/opencv/opencv.mk b/package/opencv/opencv.mk
index b9ed8cb..aa64c33 100644
--- a/package/opencv/opencv.mk
+++ b/package/opencv/opencv.mk
@@ -4,11 +4,13 @@
 #
 ################################################################################
 
-OPENCV_VERSION = 2.4.2
+OPENCV_VERSION = 2.4.6
 OPENCV_SITE    = http://downloads.sourceforge.net/project/opencvlibrary/opencv-unix/$(OPENCV_VERSION)
-OPENCV_SOURCE  = OpenCV-$(OPENCV_VERSION).tar.bz2
 OPENCV_INSTALL_STAGING = YES
+OPENCV_LICENSE = BSD-3c
+OPENCV_LICENSE_FILES = doc/license.txt
 
+OPENCV_CONF_ENV = PATH="$(TARGET_PATH)"
 OPENCV_CONF_OPT += \
 	-DCMAKE_BUILD_TYPE=$(if $(BR2_ENABLE_DEBUG),Debug,Release)   \
 	-DBUILD_SHARED_LIBS=$(if $(BR2_PREFER_STATIC_LIB),OFF,ON)    \
@@ -47,13 +49,19 @@ OPENCV_CONF_OPT += \
 	-DBUILD_opencv_nonfree=$(if $(BR2_PACKAGE_OPENCV_LIB_NONFREE),ON,OFF)   \
 	-DBUILD_opencv_objdetect=$(if $(BR2_PACKAGE_OPENCV_LIB_OBJDETECT),ON,OFF) \
 	-DBUILD_opencv_photo=$(if $(BR2_PACKAGE_OPENCV_LIB_PHOTO),ON,OFF)       \
-	-DBUILD_opencv_python=OFF                                               \
 	-DBUILD_opencv_stitching=$(if $(BR2_PACKAGE_OPENCV_LIB_STITCHING),ON,OFF) \
+	-DBUILD_opencv_superres=$(if $(BR2_PACKAGE_OPENCV_LIB_SUPERRES),ON,OFF) \
 	-DBUILD_opencv_ts=$(if $(BR2_PACKAGE_OPENCV_LIB_TS),ON,OFF)             \
 	-DBUILD_opencv_video=$(if $(BR2_PACKAGE_OPENCV_LIB_VIDEO),ON,OFF)       \
 	-DBUILD_opencv_videostab=$(if $(BR2_PACKAGE_OPENCV_LIB_VIDEOSTAB),ON,OFF) \
 	-DBUILD_opencv_world=OFF
 
+# Explicitly disable python to avoid confusing OpenCV, which comes with its
+# own implementation of the Python detection CMake module.
+OPENCV_CONF_OPT += \
+	-DBUILD_opencv_python=OFF \
+	-DPYTHON_EXECUTABLE=OFF
+
 # Hardware support options.
 #
 # * PowerPC support is turned off since its only effect is altering CFLAGS,
@@ -141,8 +149,8 @@ OPENCV_CONF_OPT += -DWITH_PNG=OFF
 endif
 
 ifeq ($(BR2_PACKAGE_OPENCV_WITH_QT),y)
-OPENCV_CONF_OPT += -DWITH_QT=ON
-OPENCV_DEPENDENCIES += qt
+OPENCV_CONF_OPT += -DWITH_QT=$(if $(BR2_PACKAGE_QT),4,5)
+OPENCV_DEPENDENCIES += $(if $(BR2_PACKAGE_QT),qt,qt5base)
 else
 OPENCV_CONF_OPT += -DWITH_QT=OFF
 endif
-- 
1.8.3.2

[Buildroot] [PATCH 1/3] qt{4, 5}: add an explicit choice to express Buildroot does not support their coexistence

[Samuel Martin]

2013/7/7 Samuel Martin <s.martin49@gmail.com>:
> Qt4 and Qt5 does not provide the same APIs; they can usually coexist on the
> same system.
> However, Buildroot does not alllow this coexistence because of some host-tools
> (qmake, etc) troubles when building qmake-based packages or projects (inside
> or outside Buildroot).
>
> So, since it is not possible to consider making a virtual package because of
> the APIs' differences, add an explicit choice.

I forgot to mention that using an explicit choice allow to get rid of
the dependency between the
Qt4 and Qt5 packages.
So, for packages supporting both Qt4 and Qt5 (like OpenCV), it makes
possible to handle the
right dependency with no circular/recursive dependency in the Config.in files.

Regards,

-- 
Samuel

[Buildroot] [PATCH 1/3] qt{4, 5}: add an explicit choice to express Buildroot does not support their coexistence

[Thomas Petazzoni]

Dear Samuel Martin,

On Sun, 7 Jul 2013 21:08:25 +0200, Samuel Martin wrote:

> I forgot to mention that using an explicit choice allow to get rid of
> the dependency between the
> Qt4 and Qt5 packages.
> So, for packages supporting both Qt4 and Qt5 (like OpenCV), it makes
> possible to handle the
> right dependency with no circular/recursive dependency in the Config.in files.

Can you give more details about this circular/recursive dependency
problem?

I'm not too enthusiastic about your PATCH 1/3, so I'd like to be sure
to completely understand what the problem is, and look at the different
possible solutions.

Thanks,

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

[Buildroot] [PATCH 3/3] opencv: bump version to 2.4.6

[Thomas Petazzoni]

Dear Samuel Martin,

On Sun,  7 Jul 2013 20:44:55 +0200, Samuel Martin wrote:
> Also:
> - add license details;
> - add new modules option;
> - explicitly disable python support to avoid being confuse by the one from the
>   host;
> - update qt support (now handle qt4/qt5)

It would probably be good if some of those changes were split in
separate patches. The license, bump, python stuff are fairly
uncontroversial, so they could get merged quickly. I believe the Qt
part will most likely require more work.

> +if BR2_INSTALL_LIBSTDCPP && (!BR2_avr32 || (BR2_USE_WCHAR && BR2_INET_IPV6 && BR2_TOOLCHAIN_HAS_THREADS)) # qt{4,5} dependencies
> +
> +if !BR2_PACKAGE_QT && !BR2_PACKAGE_QT5
> +comment "Qt support not available."
> +comment "Enable one of the Qt libraries before enabling Qt support in OpenCV"
> +endif
> +
>  config BR2_PACKAGE_OPENCV_WITH_QT
> -	bool "qt backend support"
> -	depends on BR2_INSTALL_LIBSTDCPP
> -	depends on !BR2_avr32 # qt
> -	select BR2_PACKAGE_QT
> -	select BR2_PACKAGE_QT_STL
> -	default y
> -	help
> -	  Use Qt with STL support
> +	bool "Qt support"
> +	#prompt "Qt4 support" if BR2_PACKAGE_QT
> +	#prompt "Qt5 support" if BR2_PACKAGE_QT5

Hum?

> +	depends on BR2_PACKAGE_QT || BR2_PACKAGE_QT5

Since you're using "depends on" for Qt, why do you need the complicated
BR2_INSTALL_LIBSTDCPP ... condition above?

> +	select BR2_PACKAGE_QT_STL             if BR2_PACKAGE_QT
> +	select BR2_PACKAGE_QT5BASE            if BR2_PACKAGE_QT5
> +	select BR2_PACKAGE_QT5BASE_CONCURRENT if BR2_PACKAGE_QT5
> +	select BR2_PACKAGE_QT5BASE_TEST       if BR2_PACKAGE_QT5
> +	select BR2_PACKAGE_QT5BASE_GUI        if BR2_PACKAGE_QT5
> +	select BR2_PACKAGE_QT5BASE_WIDGETS    if BR2_PACKAGE_QT5
> +
> +endif # qt{4,5} dependencies

> -OPENCV_VERSION = 2.4.2
> +OPENCV_VERSION = 2.4.6
>  OPENCV_SITE    = http://downloads.sourceforge.net/project/opencvlibrary/opencv-unix/$(OPENCV_VERSION)
> -OPENCV_SOURCE  = OpenCV-$(OPENCV_VERSION).tar.bz2
>  OPENCV_INSTALL_STAGING = YES
> +OPENCV_LICENSE = BSD-3c
> +OPENCV_LICENSE_FILES = doc/license.txt
>  
> +OPENCV_CONF_ENV = PATH="$(TARGET_PATH)"

Maybe this should be part of the CMake package infrastructure? It kind
of makes sense to execute cmake with PATH="$(TARGET_PATH)", in order to
allow cmake to pick up any host tool we might have built and installed
in $(HOST_DIR).

>  OPENCV_CONF_OPT += \
>  	-DCMAKE_BUILD_TYPE=$(if $(BR2_ENABLE_DEBUG),Debug,Release)   \
>  	-DBUILD_SHARED_LIBS=$(if $(BR2_PREFER_STATIC_LIB),OFF,ON)    \
> @@ -47,13 +49,19 @@ OPENCV_CONF_OPT += \
>  	-DBUILD_opencv_nonfree=$(if $(BR2_PACKAGE_OPENCV_LIB_NONFREE),ON,OFF)   \
>  	-DBUILD_opencv_objdetect=$(if $(BR2_PACKAGE_OPENCV_LIB_OBJDETECT),ON,OFF) \
>  	-DBUILD_opencv_photo=$(if $(BR2_PACKAGE_OPENCV_LIB_PHOTO),ON,OFF)       \
> -	-DBUILD_opencv_python=OFF                                               \
>  	-DBUILD_opencv_stitching=$(if $(BR2_PACKAGE_OPENCV_LIB_STITCHING),ON,OFF) \
> +	-DBUILD_opencv_superres=$(if $(BR2_PACKAGE_OPENCV_LIB_SUPERRES),ON,OFF) \
>  	-DBUILD_opencv_ts=$(if $(BR2_PACKAGE_OPENCV_LIB_TS),ON,OFF)             \
>  	-DBUILD_opencv_video=$(if $(BR2_PACKAGE_OPENCV_LIB_VIDEO),ON,OFF)       \
>  	-DBUILD_opencv_videostab=$(if $(BR2_PACKAGE_OPENCV_LIB_VIDEOSTAB),ON,OFF) \
>  	-DBUILD_opencv_world=OFF
>  
> +# Explicitly disable python to avoid confusing OpenCV, which comes with its
> +# own implementation of the Python detection CMake module.
> +OPENCV_CONF_OPT += \
> +	-DBUILD_opencv_python=OFF \
> +	-DPYTHON_EXECUTABLE=OFF

Why not part of the OPENCV_CONF_OPT assignment above? For the comment?

> +
>  # Hardware support options.
>  #
>  # * PowerPC support is turned off since its only effect is altering CFLAGS,
> @@ -141,8 +149,8 @@ OPENCV_CONF_OPT += -DWITH_PNG=OFF
>  endif
>  
>  ifeq ($(BR2_PACKAGE_OPENCV_WITH_QT),y)
> -OPENCV_CONF_OPT += -DWITH_QT=ON
> -OPENCV_DEPENDENCIES += qt
> +OPENCV_CONF_OPT += -DWITH_QT=$(if $(BR2_PACKAGE_QT),4,5)
> +OPENCV_DEPENDENCIES += $(if $(BR2_PACKAGE_QT),qt,qt5base)
>  else
>  OPENCV_CONF_OPT += -DWITH_QT=OFF
>  endif

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

[Buildroot] [PATCH 3/3] opencv: bump version to 2.4.6

[Samuel Martin]

Hi Thomas,

2013/7/7 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Dear Samuel Martin,
>
> On Sun,  7 Jul 2013 20:44:55 +0200, Samuel Martin wrote:
>> Also:
>> - add license details;
>> - add new modules option;
>> - explicitly disable python support to avoid being confuse by the one from the
>>   host;
>> - update qt support (now handle qt4/qt5)
>
> It would probably be good if some of those changes were split in
> separate patches. The license, bump, python stuff are fairly
> uncontroversial, so they could get merged quickly. I believe the Qt
> part will most likely require more work.
Right, will do on the next round. ;)

>
>> +if BR2_INSTALL_LIBSTDCPP && (!BR2_avr32 || (BR2_USE_WCHAR && BR2_INET_IPV6 && BR2_TOOLCHAIN_HAS_THREADS)) # qt{4,5} dependencies
>> +
>> +if !BR2_PACKAGE_QT && !BR2_PACKAGE_QT5
>> +comment "Qt support not available."
>> +comment "Enable one of the Qt libraries before enabling Qt support in OpenCV"
>> +endif
>> +
>>  config BR2_PACKAGE_OPENCV_WITH_QT
>> -     bool "qt backend support"
>> -     depends on BR2_INSTALL_LIBSTDCPP
>> -     depends on !BR2_avr32 # qt
>> -     select BR2_PACKAGE_QT
>> -     select BR2_PACKAGE_QT_STL
>> -     default y
>> -     help
>> -       Use Qt with STL support
>> +     bool "Qt support"
>> +     #prompt "Qt4 support" if BR2_PACKAGE_QT
>> +     #prompt "Qt5 support" if BR2_PACKAGE_QT5
>
> Hum?
oops!

>
>> +     depends on BR2_PACKAGE_QT || BR2_PACKAGE_QT5
>
> Since you're using "depends on" for Qt, why do you need the complicated
> BR2_INSTALL_LIBSTDCPP ... condition above?
Hmm... Good catch!
Only the comments needs the above condition.

>
>> +     select BR2_PACKAGE_QT_STL             if BR2_PACKAGE_QT
>> +     select BR2_PACKAGE_QT5BASE            if BR2_PACKAGE_QT5
>> +     select BR2_PACKAGE_QT5BASE_CONCURRENT if BR2_PACKAGE_QT5
>> +     select BR2_PACKAGE_QT5BASE_TEST       if BR2_PACKAGE_QT5
>> +     select BR2_PACKAGE_QT5BASE_GUI        if BR2_PACKAGE_QT5
>> +     select BR2_PACKAGE_QT5BASE_WIDGETS    if BR2_PACKAGE_QT5
>> +
>> +endif # qt{4,5} dependencies
>
>> -OPENCV_VERSION = 2.4.2
>> +OPENCV_VERSION = 2.4.6
>>  OPENCV_SITE    = http://downloads.sourceforge.net/project/opencvlibrary/opencv-unix/$(OPENCV_VERSION)
>> -OPENCV_SOURCE  = OpenCV-$(OPENCV_VERSION).tar.bz2
>>  OPENCV_INSTALL_STAGING = YES
>> +OPENCV_LICENSE = BSD-3c
>> +OPENCV_LICENSE_FILES = doc/license.txt
>>
>> +OPENCV_CONF_ENV = PATH="$(TARGET_PATH)"
>
> Maybe this should be part of the CMake package infrastructure? It kind
> of makes sense to execute cmake with PATH="$(TARGET_PATH)", in order to
> allow cmake to pick up any host tool we might have built and installed
> in $(HOST_DIR).
yup.

>
>>  OPENCV_CONF_OPT += \
>>       -DCMAKE_BUILD_TYPE=$(if $(BR2_ENABLE_DEBUG),Debug,Release)   \
>>       -DBUILD_SHARED_LIBS=$(if $(BR2_PREFER_STATIC_LIB),OFF,ON)    \
>> @@ -47,13 +49,19 @@ OPENCV_CONF_OPT += \
>>       -DBUILD_opencv_nonfree=$(if $(BR2_PACKAGE_OPENCV_LIB_NONFREE),ON,OFF)   \
>>       -DBUILD_opencv_objdetect=$(if $(BR2_PACKAGE_OPENCV_LIB_OBJDETECT),ON,OFF) \
>>       -DBUILD_opencv_photo=$(if $(BR2_PACKAGE_OPENCV_LIB_PHOTO),ON,OFF)       \
>> -     -DBUILD_opencv_python=OFF                                               \
>>       -DBUILD_opencv_stitching=$(if $(BR2_PACKAGE_OPENCV_LIB_STITCHING),ON,OFF) \
>> +     -DBUILD_opencv_superres=$(if $(BR2_PACKAGE_OPENCV_LIB_SUPERRES),ON,OFF) \
>>       -DBUILD_opencv_ts=$(if $(BR2_PACKAGE_OPENCV_LIB_TS),ON,OFF)             \
>>       -DBUILD_opencv_video=$(if $(BR2_PACKAGE_OPENCV_LIB_VIDEO),ON,OFF)       \
>>       -DBUILD_opencv_videostab=$(if $(BR2_PACKAGE_OPENCV_LIB_VIDEOSTAB),ON,OFF) \
>>       -DBUILD_opencv_world=OFF
>>
>> +# Explicitly disable python to avoid confusing OpenCV, which comes with its
>> +# own implementation of the Python detection CMake module.
>> +OPENCV_CONF_OPT += \
>> +     -DBUILD_opencv_python=OFF \
>> +     -DPYTHON_EXECUTABLE=OFF
>
> Why not part of the OPENCV_CONF_OPT assignment above? For the comment?
Yes, for the comment.

>
>> +
>>  # Hardware support options.
>>  #
>>  # * PowerPC support is turned off since its only effect is altering CFLAGS,
>> @@ -141,8 +149,8 @@ OPENCV_CONF_OPT += -DWITH_PNG=OFF
>>  endif
>>
>>  ifeq ($(BR2_PACKAGE_OPENCV_WITH_QT),y)
>> -OPENCV_CONF_OPT += -DWITH_QT=ON
>> -OPENCV_DEPENDENCIES += qt
>> +OPENCV_CONF_OPT += -DWITH_QT=$(if $(BR2_PACKAGE_QT),4,5)
>> +OPENCV_DEPENDENCIES += $(if $(BR2_PACKAGE_QT),qt,qt5base)
>>  else
>>  OPENCV_CONF_OPT += -DWITH_QT=OFF
>>  endif
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com



-- 
Samuel

[Buildroot] [PATCH 1/3] qt{4, 5}: add an explicit choice to express Buildroot does not support their coexistence

[Samuel Martin]

Hi Thomas, all,

2013/7/7 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Dear Samuel Martin,
>
> On Sun, 7 Jul 2013 21:08:25 +0200, Samuel Martin wrote:
>
>> I forgot to mention that using an explicit choice allow to get rid of
>> the dependency between the
>> Qt4 and Qt5 packages.
>> So, for packages supporting both Qt4 and Qt5 (like OpenCV), it makes
>> possible to handle the
>> right dependency with no circular/recursive dependency in the Config.in files.
>
> Can you give more details about this circular/recursive dependency
> problem?
Sure.

All this work starts with the OpenCV bump, which the latest version
provides support for Qt4
and Qt5.
What I'd like to do at first was:
- if no Qt version was selected beforehand, and one wants to enable Qt
support in OpenCV,
then the Qt version is set via the OpenCV choice;
- if the Qt version is set beforehand, then just allow to enable the
Qt support (no choice, the
one already selected) in OpenCV.

Basically, I tried using a choice; roughly:
---
choice
  prompt "Qt support"

config BR2_OPENCV_WITH_QT_NONE
  bool "none"

config BR2_OPENCV_WITH_QT4
  bool "Qt4"
  depends on !BR2_PACKAGE_QT5
  select BR2_PACKAGE_QT
  ...

config BR2_OPENCV_WITH_QT5
  bool "Qt5"
  depends on !BR2_PACKAGE_QT
  select BR2_PACKAGE_QT5
  ...

endchoice
---


With the current Qt/Qt5 package exclusion mechanism:
---
config BR2_PACKAGE_QT
  ...

config BR2_PACKAGE_QT5
  depends on !BR2_PACKAGE_QT
  ...
---
as you can easily spot, the OpenCV Qt4 support option generate a
circular dependency.


Later, after converting the Qt{4,5} exclusion mechanism to the
proposed explicit choice,
the 'select BR2_PACKAGE_QT{,5}' statements in the OpenCV Qt support
options had no effect,
so I turn them in one unique option, depending on one or the other Qt
version, and selecting
Qt components accordingly.
I think I missed something on this latter issue, but submit it as to
get other people's opinion.


>
> I'm not too enthusiastic about your PATCH 1/3, so I'd like to be sure
> to completely understand what the problem is, and look at the different
> possible solutions.
Hope I'm clear enough.

Regards,

-- 
Samuel