How to get Cmake to find OpenCL if it was installed via vcpkg?

I am currently using the following guide to try to get a basic OpenCL example working in a Windows environment: https://github.com/KhronosGroup/OpenCL-Guide/blob/main/chapters/getting_started_windows.md

They use the following cmake:

cmake_minimum_required(VERSION 3.1) # 3.1 << C_STANDARD 11

project(HelloOpenCL LANGUAGES C)

find_package(OpenCL CONFIG REQUIRED)

add_executable(${PROJECT_NAME} Main.c)

target_link_libraries(${PROJECT_NAME} PRIVATE OpenCL::OpenCL)

set_target_properties(${PROJECT_NAME} PROPERTIES C_STANDARD 11
                                                 C_STANDARD_REQUIRED ON
                                                 C_EXTENSIONS OFF)

target_compile_definitions(${PROJECT_NAME} PRIVATE CL_TARGET_OPENCL_VERSION=100)

If I run the following command from within the source folder:

cmake -A x64 -S . -B .\build -D CMAKE_TOOLCHAIN_FILE=C:\src\vcpkg\scripts\buildsystems\vcpkg.cmake

Then it fails with the following error:

CMake Error at C:/src/vcpkg/installed/x64-windows/share/opencl/vcpkg-cmake-wrapper.cmake:1 (_find_package):
  Could not find a package configuration file provided by "OpenCL" with any
  of the following names:

    OpenCLConfig.cmake
    opencl-config.cmake

Those files don't exist anywhere on my system, I'm assuming because I installed openCL using vcpkg.

How do I get cmake to find my OpenCL? FindOpenCL's page is quite sparse, but maybe I need to provide some kind of "hint" as to OpenCL's location?

There is a Cmake support section, but I'm not seeing anything useful there either. It pretty much just says that it should work as they wrote it.

I did make sure to include --triplet x64-windows when I installed OpenCL using vcpkg.

Solution

I have zero idea why because I don't use vcpkg, but removing the CONFIG constraint from the find_package call (which forces find_package to use the config search mode) seems to resolve the problem.

Docs on using packages with vcpkg
Docs on CMake find_package search modes. Here's a snippet from the docs:

When the basic signature is used, the command searches in Module mode first. If the package is not found, the search falls back to Config mode. A user may set the CMAKE_FIND_PACKAGE_PREFER_CONFIG variable to true to reverse the priority and direct CMake to search using Config mode first before falling back to Module mode.
See also VCPKG_TRACE_FIND_PACKAGE

I also see the asker of this question opened an issue ticket with the maintainers: https://github.com/KhronosGroup/OpenCL-Guide/issues/29. The maintainers gave some explanation of what's going on in the comments there:

There are a few things to patch up, all of which will be tackled shortly.

The vcpkg port doesn't wrap the OpenCL-SDK repo, because when I last tackled it, it wouldn't have simplified much in the port, because Vcpkg is lacking the ability to clone with submodules. It is when one installs the OpenCL-SDK superproject that CONFIG support works. find_package(OpenCL CONFIG) is a Khronos OpenCL-SDK thing (until Linux distros or vendor SDKs don't pick up this interface). Until the Vcpkg port doesn't wrap the OpenCL-SDK explicitly and continues to assemble the components one-by-one, Vcpkg won't work with CONFIG.

COMPONENTS for the moment is a CONFIG-only feature, but that is to change shortly. I'm in the final stages of testing my contribution to Kitware's FindOpenCL.cmake which will add component support to the MODULE-mode search syntax. (I'm stuck on include path issues on MacOS with XCode only.)

Once both of these are implemented (and likely both are going to land sometime during the summer), it will not matter which syntax you use to consume OpenCL from Vcpkg and whether you use components in MODULE or COMPONENT mode.