Updated library exports

[mshabunin]

replaces #8073
build with opencv/opencv_contrib#996

This pullrequest changes

• use GenerateExportHeader
• fixed problems with exports and imports

build_world:Win64 MSVS2017 OpenCL=ON
#build_shared:Win64 OpenCL=OFF
allow_multiple_commits=1

[vpisarev]

@mshabunin, looks like the patch needs to be updated; sorry for not merging it earlier :(

[mshabunin]

@vpisarev , this patch is not compatible with #8461, because I've removed all CV_EXPORTS statements in the ts module. First we need to choose either #8461 (build and install ts module in separate package during OpenCV build) either #8468 (separately build standalone ts library). After that I will update this patch.

[alalek]

"PIC" is needed for Python/Java bindings only.
For using OpenCV with applications it is not required at all.

[mshabunin]

This is a port of block removed from OpenCVCompilerOptions.cmake. We always enable PIC because static libraries can be used to build some shared libraries, I wanted to preserve this ability.

[alalek]

Need to revert this change.

[alalek]

Comment is not consistent with following code.
Android application native library should not export OpenCV API

[mshabunin]

We build native static libraries and "fat Java lib" for Android in one build (-DBUILD_SHARED_LIBS=OFF -DBUILD_FAT_JAVA_LIB=ON). We need to export all symbols for the second artifact. Currently all symbols are exported in static builds on all platforms, this PR changes this behavior for all platforms except Android. I can only suggest reworking "fat Java lib" artifact, so that it will be produced same way as opencv_world module (-DBUILD_SHARED_LIBS=ON -DBUILD_opencv_world=ON -DBUILD_FAT_JAVA_LIB=ON), but it cat take more time to investigate.

[alalek]

Fat Java library is artifact for Android manager which is deprecated.
If application doesn't use Java API (doesn't require libopencv_java.so), so there is no reason to bundle whole OpenCV code into Android application.
More accurate way is no link with application JNI library with static OpenCV libraries - libopencv_core.a/etc. So we need to drop global exported symbols from these OpenCV static libraries.

So, there are 2 different builds:

• static libopencv_<>.a with global exported symbols => libopencv_java.so
• static libopencv_<>.a without global exported symbols and without any libopencv_java.so. Useful for using OpenCV API from native C++ code only (without any OpenCV Java bindings).

[alalek]

CV_EXPORTS_TEMPLATE is not expected by bindings parser.

[mshabunin]

Currently bindings generators do not support templates, so we don't need it for now. We can easily add CV_EXPORTS_TEMPLATE_W macro if such functionality will be implemented.

[alalek]

I still do not understand what kind of problem should be resolved by this patch.
It removes OpenCV's CV_EXPORTS (and removes ability to adjust/customize this macro) and replaces with some CMake stuff (which probably depends on used CMake version). I believe this approach has very limited usage. Android "block" is an example that CMake can't target anything, especially cross-platform cases with custom toolchains.

[mshabunin]

This patch does not remove CV_EXPORTS macro, it changes the macro behavior depending on build configuration: dynamic builds will have same definitions as current version does, static builds will set it to empty.
The GenerateExportHeader module from cmake is rather simple and we can replace it with our own generated header when we need it, but I think that at this moment we can use it as-is. Problem with Android block takes its' roots in opencv_java module and "non-trivial" "fat Java lib" feature implementation. We can remove it if we will rework the Android package.