Env setup for testing package implemented using /etc/profile.d;
Variable with path for all native samples added;
Path for test binaries and test data updated.
If it's followed by a slash and OpenCV_INSTALL_BINARIES_PREFIX is empty,
then the resulting path becomes absolute.
Fixes <http://code.opencv.org/issues/3350>.
- crosses initializations in "cap_ximea.cpp" (which also contained some awfull "goto" instructions)
- the "CMAKE_CL_64" variable is not initialized when using mingw
PR#1039 modified to be able to merge on branch 2.4
include() doesn't create a variable scope, so the settings of
CMAKE_MODULE_PATH and CMAKE_FIND_ROOT_PATH_MODE_* were polluting
everything included after OpenCVDetectCUDA.cmake.
Also, FindCUDA includes FindPackageHandleStandardArgs, which includes
CMakeParseArguments, which causes warnings related to policy CMP0017.
Setting it to NEW seems safe enough.
replaced find_host_package with find_package and
set CMAKE_FIND_ROOT_PATH_MODE_LIBRARY to BOTH, because NEVER
doesn't work for CUDA_CUDA_LIBRARY, which is located in
/usr/arm-linux-gnueabihf/lib/libcuda.so for ARM
The reasons for that are twofold:
1) LINK_PRIVATE is only available since CMake 2.8.7.
2) The way it was used generated a warning because of CMake policy CMP0023:
http://www.cmake.org/cmake/help/v2.8.12/cmake.html#policy:CMP0023
Using LINK_INTERFACE_LIBRARIES actually causes another warning - this time
because of CMake policy CMP0022:
http://www.cmake.org/cmake/help/v2.8.12/cmake.html#policy:CMP0022
I set the policy to OLD, because NEW means subtle changes when compiling
with CMake 2.8.12, and I don't want to research that this close to release.
:-)
I also removed the setting of CMP0003, because it's set by
cmake_minimal_version anyway.
The patch was submitted to CMake and might be available
in the next CMake release.
But until we have the fix in CMake we should add workaround in our scripts.