Without the fix, OpenCV will compile and silently copy the compiled libs/executables to a location not prefixed with arch/vc14, and OpenCV won't be picked up by find_package and OpenCVConfig.cmake.
If used cl compiler, but generator is not Visual Studio e.g. Ninja,
enable FS option to prevent blocking PDB file in multithreaded build.
(cherry picked from commit 58c9135626)
Which also happens to align the non-Debian specific variables
with the ones used by upstream CMake.
(cherry picked from commit b8c60234c3)
Conflicts:
cmake/OpenCVPackaging.cmake
Install symlinks to shared libraries as a part of development package,
not runtime package.
It is default behavior for debian packages.
(cherry picked from commit f55c1cc0fb)
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.
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.
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.
Since we are actually interested in finding the "64" in the
triplet's operating system key, this fix makes sure to look for
"mingw64" and thus avoids the false match.
Fixes issue #3835. Credits to Lode Leroy for the original patch.
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.
The use of built-in CMAKE_CURRENT_LIST_DIR requires at least
CMake 2.8.3. This fix properly defines the variable to allow its
use in versions < 2.8.3 as well.
Fixes issue #4205.