[opencv4] build failure

[neko-para]

Operating system

Windows

Compiler

MSVC

Steps to reproduce the behavior

Please refer to [this build](https://github.com/MaaAssistantArknights/MaaDeps/actions/runs/6408548734/job/17397796786)

Failure logs

-- Could NOT find HDF5 (missing: HDF5_LIBRARIES HDF5_INCLUDE_DIRS) (found version "")
CMake Error in E:/Projects/MAA/MaaFramework/MaaDeps/vcpkg/installed/maa-x64-windows/share/opencv4/OpenCVModules.cmake:
  cmake_policy PUSH without matching POP
Call Stack (most recent call first):
  E:/Projects/MAA/MaaFramework/MaaDeps/vcpkg/installed/maa-x64-windows/share/opencv4/OpenCVConfig.cmake:126 (include)
  E:/Projects/MAA/MaaFramework/MaaDeps/vcpkg/scripts/buildsystems/vcpkg.cmake:859 (_find_package)
  CMakeLists.txt:6 (find_package)

Additional context

I want to disable HDF5 for opencv, as it cannot be cross compiling.

if (PORT STREQUAL "opencv")
    list(APPEND VCPKG_CMAKE_CONFIGURE_OPTIONS -DBUILD_opencv_hdf=OFF)
endif ()

With script above in triplet file, opencv DO stop depending on it. But when another library depending on opencv, the OpenCVModules.cmake always want to find hdf5.

find_dependency(Threads)
find_dependency(TIFF)
# C language is required for try_compile tests in FindHDF5
enable_language(C)
find_dependency(HDF5) # <-- it always wants to find HDF5
find_dependency(Tesseract)
find_dependency(Eigen3 CONFIG)

[neko-para]

According to the portfile.cmake

  if(BUILD_opencv_quality AND "contrib" IN_LIST FEATURES)
    string(APPEND DEPS_STRING "
# C language is required for try_compile tests in FindHDF5
enable_language(C)
find_dependency(HDF5)
find_dependency(Tesseract)")
  endif()

I'm not sure if I should use BUILD_opencv_quality instead of BUILD_opencv_hdf.

[FrankXie05]

Yes, you can use this BUILD_opencv_quality=OFF to disable to find HDF5.

[neko-para]

Yes, you can use this BUILD_opencv_quality=OFF to disable to find HDF5.

After some of tries, setting BUILD_opencv_quality seems don't stop generating that find_dependency(HDF5). Thus, I dup it into overlay and comment that set which finally work.

# Build image quality module when building with 'contrib' feature and not UWP.
set(BUILD_opencv_quality OFF)
if("contrib" IN_LIST FEATURES)
#[[
  if (VCPKG_TARGET_IS_UWP OR VCPKG_TARGET_IS_IOS OR (VCPKG_TARGET_ARCHITECTURE MATCHES "arm" AND VCPKG_TARGET_IS_WINDOWS))
    set(BUILD_opencv_quality OFF)
    message(WARNING "The image quality module (quality) does not build for UWP or iOS, the module has been disabled.")
    # The hdf module is silently disabled by OpenCVs buildsystem if HDF5 is not detected.
    message(WARNING "The hierarchical data format module (hdf) depends on HDF5 which doesn't support UWP or iOS, the module has been disabled.")
  else()
    set(BUILD_opencv_quality CMAKE_DEPENDS_IN_PROJECT_ONLY)
  endif()
#]]
  set(BUILD_opencv_quality OFF)

Actually, I don't really understand that set(BUILD_opencv_quality CMAKE_DEPENDS_IN_PROJECT_ONLY). Is it the reason why those find_dependencys still been generated?

[dg0yt]

Given that you had a successful opencv4 build before, this buildsystem already handles the absence of hdf5, so it doesn't really need a different configuration.

And you already pointed out that it is the portfile which adds the unconditional find_dependency(HDF5).

So as a simple mitigation, change that line in the portfile to find_package(HDF5). This will find HDF5 when it is available, and won't complain if it isn't.

(The proper solution is a patch.)

[neko-para]

As shown in cmake file above and also in pkg json, hdf5 is disabled when targetting uwp, ios or win-arm64. However, hdf5 can hardly cross compiling(after all, targetting linux-arm64 or mac-arm64 on x86 machine caused failure). I wonder if there would be a flag or option to mark it, as linux-arm64 should be built on arm machine, thus cannot simply disable it because of arch.

---

Also, I'm quite unfamilar with the vcpkg patch logic. I know that it's possible to patch the source, but is it possible to patch the portfile.cmake or the installed files?

[github-actions[bot]]

This is an automated message. Per our repo policy, stale issues get closed if there has been no activity in the past 28 days. The issue will be automatically closed in 14 days. If you wish to keep this issue open, please add a new comment.

[github-actions[bot]]

This is an automated message. Per our repo policy, stale issues get closed if there has been no activity in the past 28 days. The issue will be automatically closed in 14 days. If you wish to keep this issue open, please add a new comment.