The INSTALL_NAME_DIR property of a target specifies how a dynamic library should
be found on OS X. If INSTALL_NAME_DIR is not specified the loader will search
relative to the standard search paths. If specified it should either be
an absolute path or relative path prefixed with either @executable_path,
@load_path, or @rpath. Specifying "lib" does not make sense here and
causes linking error as documented here:
http://answers.opencv.org/question/4134/cmake-install_name_tool-absolute-path-for-library-on-mac-osx/
and here
http://stackoverflow.com/questions/26978806/dyld-library-not-loaded-lib-libopencv-core-3-0-dylib-reason-image-not-found
This patch removes INSTALL_NAME_DIR everywhere it is set to "lib".
An alternate solution would be to set an absolute path like
"${CMAKE_INSTALL_PREFIX}/lib" or relative path like
"@executable_path/../lib". However, if there is not specific need for
specifying a path, it is probably best left unset.
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.
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.
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.
Sometimes information about dependencies causing disabling were loosed and it
was not possible to correctly display these dependencies in status report
