I am trying to get rid of part of the path that OpenCV hard-codes in its *.cmake config files (OpenCVConfig, OpenCVConfig-version, OpenCVModulesandOpenCVModules-`) when building and installing it from source.

Background

For the configuration and building steps of OpenCV (currently without contributed modules) I run, e.g. (debug build)

cmake -Bbuild -S. -G "Visual Studio 16 2019" -DCMAKE_CONFIGURATION_TYPES="debug"
cmake --build build --target ALL_BUILD --config "debug"

Note: More on why I set CMAKE_CONFIGURATION_TYPES manually later.

The installation step is respectively

cmake --build build --target install --config "debug"

This creates an install directory that contains (among other things)

• headers files
• runtime files (mostly dlls)
• libraries (libs) and *.cmake files (previously mentioned)

My project is pretty large and I have a repository that is dedicated just on building and uploading dependencies as artifacts that I download and use in my main project (again CMake). Using GitLab CI all other dependencies ship artifacts with the following structure:

<artifacts-root>/<build-type>/lib
<artifacts-root>/<build-type>/bin
<artifacts-root>/<build-type>/include

Specifying CMAKE_CONFIGURATION_TYPES limits the processing of a CI job that is meant for a single configuration type anyway.

OpenCV, due to its support for multiple compilers and architectures, provides a more complex output directory structure. In my case (Windows 10, MSVC 16) I something similar to

<opencv-install-dir>/x64/vc16/bin
<opencv-install-dir>/x64/vc16/lib

Since I am not looking for multi-compiler or multi-arch support, I would like to bring OpenCV’s installation directory to form that fits my other dependencies.

Attempts

I tried specifying the CMAKE_INSTALL_PREFIX without any success. I actually checked the *.cmake files inside the lib dir and found out that (here opencv_core module)

OpenCVModules.cmake:

get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
if(_IMPORT_PREFIX STREQUAL "/")
  set(_IMPORT_PREFIX "")
endif()

# Create imported target opencv_core
add_library(opencv_core SHARED IMPORTED)

OpenCVModules-release.cmake

set_property(TARGET opencv_core APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(opencv_core PROPERTIES
  IMPORTED_IMPLIB_RELEASE "${_IMPORT_PREFIX}/x64/vc16/lib/opencv_core4100.lib"
  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/x64/vc16/bin/opencv_core4100.dll"
  )

meaning that changing the installation prefix still puts architecture and compiler components in the path (so the resulting *.cmake have it hard-coded).

Is there a way using CMake tool to enforce a specific structure for the output directory and especially the one for installing since I take those contents as artifacts? When I try to use the artifacts CMake is telling me that

CMake Error at LOCAL_DEPS/artifacts/lib/OpenCVModules.cmake:179 (message):
  The imported target "opencv_core" references the file

     "C:/Users/user/Projects/libtorch-basics/x64/vc16/lib/opencv_core4100.lib"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "C:/Users/user/Projects/libtorch-basics/LOCAL_DEPS/artifacts/lib/OpenCVModules.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  LOCAL_DEPS/artifacts/lib/OpenCVConfig.cmake:126 (include)
  CMakeLists.txt:175 (find_package)

which means OpenCV’s config files are still looking for <opencv-install-dir>/x64/vc16/*. Not there yet, but I am almost certain I will also get problems with the include directory, which is at <opencv-install-dir>include.

I do believe this is a more general issue then just OpenCV so I am fine with possible solutions for other projects.

Another thing I am checking out right now is to do the installation step only to generate the headers but copy the rest from the original build directory. Come to think of it, it does make sense for the CMake config file to include a partially hard-coded sub-path.