I may not understand this completely, but this PR seems to be not needed? I am looking at the find_package() documentation, and the path searching logic reads:

<prefix>/                                               (W)
<prefix>/(cmake|CMake)/                                 (W)
<prefix>/<name>*/                                       (W)
<prefix>/<name>*/(cmake|CMake)/                         (W)
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/          (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/                (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/  (U)

My original path should correspond to the 4th row on windows and the 7th row on unix? Where does the cmake string precede the lib name? Is it not working for you?

The unofficial consensus on Linux is to use option 5. Never came across a project using option 7 TBH. Besides, this would make things consistent with other clMath projects and ArrayFire, which is always welcome from a package maintenance point-of-view.

Your call.

Strange how the eyes skip strings, they didn't register option 5. It's marked U, have you tested that path on windows?

have you tested that path on windows?

No

For Windows, I would rather rely on the user providing a set of paths via the CMAKE_MODULE_PATH cmake option, since there is no such things as a common installation tree like /usr in Linux. Most projects have dealt with either use the same as on Linux (option 5) or use option 2 if windows is detected.

Let me insist on this issue from a packaging point-of-view. I am the current maintainer of clBLAS, clFFT, and I am intending to package clSPARSE and clRNG as well. All these projects have similar build structures and cmake lists layout, which means I can share patches between projects resulting in significantly less maintenance overhead.

If you could, please link to other projects that use the configure_package_config_file() macro. It would be good to see/study how others do it.
I will consider the change, but I need time to see how it affects windows. I need something that works cross-platform.

Please correct me if I am wrong but all CONFIGURE_PACKAGE_CONFIG_FILE does is create a sane and relocatable FooConfig.cmake. So whether a project uses this macro or not does not matter for this issue, as long as the resulting FooConfig.cmake file is installed in an appropriate location for the cmake detection to work.

Then, an example from another clMathLibraries project, clFFT:

if(WIN32)
  set(destdir CMake)
else()
  set(destdir share/clFFT)
endif()
string(REGEX REPLACE "[^/]+" ".." reldir "${destdir}")
configure_file(
  ${CMAKE_CURRENT_SOURCE_DIR}/clFFTConfigVersion.cmake.in
  ${CMAKE_CURRENT_BINARY_DIR}/clFFTConfigVersion.cmake
  @ONLY)
configure_file(
  ${CMAKE_CURRENT_SOURCE_DIR}/clFFTConfig.cmake.in
  ${CMAKE_CURRENT_BINARY_DIR}/clFFTConfig.cmake
  @ONLY)
install(EXPORT Library DESTINATION ${destdir} FILE clFFTTargets.cmake)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/clFFTConfigVersion.cmake
  ${CMAKE_CURRENT_BINARY_DIR}/clFFTConfig.cmake
  DESTINATION ${destdir})

which I am currently patching share/clFFT to become lib/<arch>/cmake/clFFT. Hence, myself asking for a little bit of consistency...