- Recommended compiler checks:
- GCC: CV_GCC
- Clang: CV_CLANG
- fixed problem with CMAKE_CXX_COMPILER_ID=Clang/AppleClang mess on MacOSX
Details: cmake --help-policy CMP0025
- do not declare Clang as GCC compiler
This retains the desirable quality of not including paths to CUDA libraries
from the build system into the config files, and has two major advantages:
* It removes the need to use link_directories, which doesn't guarantee that
the libraries from the supplied directory will be used (there may be
libraries with the same names earlier in the search path).
* It removes the need to put -L entries into OPENCV_LINKER_LIBS. This variable
is used with target_link_libraries, where such entries are treated as linker
flags, so doing this is unportable. I remove the support for -L entries
from OpenCVGenPkgconfig.cmake, as well, to discourage adding them in the
future.
* improve `CUDA_TARGET_CPU_ARCH` cache initialization,
allow to override initial value from calling script;
* add `CUDA_TARGET_OS_VARIANT` option to select OS variant;
* add `CUDA_TARGET_TRIPLET` option to select target triplet from
`${CUDA_TOOLKIT_ROOT_DIR}/targets` folder;
* remove `CUDA_TOOLKIT_TARGET_DIR` option, now it is calculated from
`CUDA_TARGET_TRIPLET`, the old approach still can be used for compatibility;
* for CUDA 6.5 and newer try to locate static libraries too, because
in 6.5 toolkit for ARM cross compilation only static libraries are included.
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 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.