If both Python 2 and Python 3 are found, then build bindings for both of
them during the build process. Currently, one version of Python is
detected automatically, and building for the other requires changes the
CMake config.
The largest chunk of this change generalizes OpenCVDetectPython.cmake to
find both a Python 2 and Python 3 version of Python. Secondly, the
opencv_python module is split into two modules, opencv_python2 and
opencv_python3. Both are built from the same source. but for different
versions of Python.
EMBED_CUDA and FORCE_EMBED_OPENCV flags added to cmake macro add_android_project;
INSTALL_CUDA_LIBRARIES option added to OpenCV.mk
opencv_dynamicuda library installation with enabled OPENCV_INSTALL_MODULES flag fixed;
CUDA initialization apportunity added to OpenCVLoader.initDebug();
Tutorial-4-CUDA sample reimplemented with static OpenCV and CUDA initialization.
(cherry picked from commit 6ae4a9b09b)
CV_CAP_PROP_SUPPORTED_PREVIEW_SIZES_STRING property is not supported
by all VideoCapture backends. Some backends can return 0.0 or -1.0.(cherry picked from commit c41e8006c7)
EMBED_CUDA and FORCE_EMBED_OPENCV flags added to cmake macro add_android_project;
INSTALL_CUDA_LIBRARIES option added to OpenCV.mk
opencv_dynamicuda library installation with enabled OPENCV_INSTALL_MODULES flag fixed;
CUDA initialization apportunity added to OpenCVLoader.initDebug();
Tutorial-4-CUDA sample reimplemented with static OpenCV and CUDA initialization.
The paths are defined properly with an escape "\ " but you cannot have an escape and
quotes when piping (otherwise, escapes are understood as 2 characters).
So just remove the quotes.
Previously, run.py would assume that the opencv_java library is in the
same directory as the tests, which is only true on Windows.
The library path depends on the build configuration, which may not be
known until the actual build (e.g. with the Visual Studio generators),
so it can't be stored in the CMake cache for run.py to read. I didn't
want to hardcode into run.py where the library is on each platform,
either. So that's why I used the current scheme with the properties
file. It also makes running the tests without run.py a little easier.
Java inlines static finals if they're defined with a constant expression. In
case of version constants we don't want that to happen, since they obviously
change from version to version. If the user substitutes a different OpenCV
jar without recompiling, we want user code to still have relevant values for
the version constants.
This arranges that by turning constant values into function calls, which no
longer count as a constant expression.