How this worked before, I do not know.

The check for BUILD_SHARED_LIBS had its logic backwards. If this
variable is not defined we must assume a build of static libs.

Make detection of x64 using the gcc's target triplet identical
to the one used in cmake/OpenCVDetectCXXCompiler.cmake.
Otherwise, MinGW-w64 setups will always be treated as x64 since
they contain "w64" as vendor key.

Fix typo that would always lead to detection of x86 for MinGW
builds in the OpenCVConfig.cmake file.

MinGW-w64 always uses "w64" as vendor key which the previously
used check for "64" anywhere in the target triplet matched. This
would lead to MinGW-w64 setups always being treated as x64.

Turns out we do not even need this additional check since the
architecture has been correctly determined earlier in this file.
No need to do it again.

HAVE_VFW flag is defined by CMake try_compile check.

Check fails for WINRT as vfw.h begins with

and contains empty set of functions for Store apps.

So we can safely remove vfw32.lib for WINRT in general

(independently of availability for specific configuration)

Everything else depends on it, after all.

(cherry picked from commit cf54e3b9)

Conflicts:
	cmake/OpenCVPackaging.cmake

(cherry picked from commit 6d52ea89)

Which also happens to align the non-Debian specific variables
with the ones used by upstream CMake.

(cherry picked from commit b8c60234)

Conflicts:
	cmake/OpenCVPackaging.cmake

It's pretty much a simplified copy of the Linux script, lacking fancy colors.
Also, I had to drop Python testing, because it's not easy to pass the Python
module location to the script, and I have no pressing need to run the Python
tests at the moment.

(cherry picked from commit c1e3ca17)

Conflicts:
	CMakeLists.txt

They don't actually do anything. And even if they did, all components are
enabled by default, anyway.

(cherry picked from commit 49fe4969)

Conflicts:
	cmake/OpenCVPackaging.cmake

looks like Maksim was right; the new fix does not do the second attempt to detect python libs, it finds it correctly with the first attempt

explained reason why IPP is disabled on 32-bit Linux. disable IPP's minMaxLoc_32f on 32-bit OSes only

2) disable IPP on 32-bit Linux when OpenCV is built as shared libs. Otherwise we get linker errors
3) disable IPP's minMaxIdx 32-bit floating-point flavor in a hope that it fixes some test failures

 - explicitly turning OCL off since WinRT does not support it
 - fixing macro definitions in core/ocl.cpp
Signed-off-by: Maxim Kostin <v-maxkos@microsoft.com>

- Substituted HAVE_WINRT with WINRT
- Fixed compilation issues in ocl.cpp and parallel.cpp
- Fixed compiler issue for WP8: "C2678: binary '+' : no operator found which takes a left-hand - Fixed gitignore
- Added #ifdef HAVE_OPENCL to remove compiler warnings in ocl.cpp
- Used NO_GETENV similar to '3rdparty\libjpeg\jmemmgr.c;
- Added ole32.lib for core module (for WindowsStore 8.0 builds)
- Made OpenCV_ARCH aware of ARM
Signed-off-by: Maxim Kostin <v-maxkos@microsoft.com>

Add check for CUDA version >= 7.0 (currently in RC1), which drops support for arches 1.x.

use `bash` shell instead of `sh`, since on Ubuntu `sh` by default is `dash`,
and `dash` doesn't support `PIPESTATUS` feature used in this sctipt