No. There is a test port in vcpkg which makes sure lapack can be found the way it is.

And the canonical way to use lapack is via find_package(Lapack) via module and not config mode

And the canonical way to use lapack is via find_package(Lapack) via module and not config mode

When using config mode in the original usage, it will prompt that lapack.lib cannot be opened when compiling the generated project.

find_package(lapack CONFIG REQUIRED)
target_link_libraries(main PRIVATE lapack)

Well, the guidelines disallow renaming after the build because of CMake config.

Could we just patch out these lines:
https://github.com/Reference-LAPACK/lapack/blob/7295ac130f1d880e10c4412b6b524498f0538635/CMakeLists.txt#L14-L15

This work probably got reset by merging #24327

The changes of this PR ignoring WS changes looks strange to me.

The change to lapack-reference looks correct to me (they just implement https://learn.microsoft.com/en-us/vcpkg/contributing/maintainer-guide#do-not-rename-binaries-outside-the-names-given-by-upstream ). Can you explain how the opencv4 and openmvs changes are related?

Thanks! <3

The reason for modifying opencv4 and openmvs is that when ci is running, it prompts: opencv4 cannot find the flatbuffers header file, so the flatbuffers search method is fixed. openmvs prompts that zstd cannot be found when connecting, because #32309 is not merged yet and FindBoost only knows about transitive usage requirements within boost itself.

@jimwang118 Actually, it looks like this PR broke opencv4. vcpkg install opencv4[core] now fails with an error that flatbuffers was not found. vcpkg install opencv4 doesn't fail because that pulls in flatbuffers as a vcpkg dependency. However I don't think opencv4[core] needs flatbuffers, so it should not fail and not even look for flatbuffers. Before this PR (vcpkg baseline from Sep 2023), vcpkg install opencv4[core] installed fine, without needing flatbuffers.

So what I think might be happening is that the old method include(cmake/OpenCVDetectFlatbuffers.cmake) had some conditional logic inside to not require/find flatbuffers when only opencv4[core] is requested, and the new line find_package(flatbuffers CONFIG REQUIRED) is unconditionally requesting flatbuffers (which is likely wrong).

@jimwang118 Actually, it looks like this PR broke opencv4. vcpkg install opencv4[core] now fails with an error that flatbuffers was not found. vcpkg install opencv4 doesn't fail because that pulls in flatbuffers as a vcpkg dependency. However I don't think opencv4[core] needs flatbuffers, so it should not fail and not even look for flatbuffers. Before this PR (vcpkg baseline from Sep 2023), vcpkg install opencv4[core] installed fine, without needing flatbuffers.

So what I think might be happening is that the old method include(cmake/OpenCVDetectFlatbuffers.cmake) had some conditional logic inside to not require/find flatbuffers when only opencv4[core] is requested, and the new line find_package(flatbuffers CONFIG REQUIRED) is unconditionally requesting flatbuffers (which is likely wrong).

This issue is fixing by PR 38594.

Ah great, thanks! I think that PR wasn't merged yet when I was running into the problem yesterday. I'll pull the latest vcpkg now.