codeplaysoftware
Has ComputeCpp_DIR worked, ever?
I was creating uni material on Windows, so I have to be surfing the experimental CE compiler, for which the installer doesn't seem to register the COMPUTECPP_DIR env var. (Which makes sense, the experimental compiler is hesitant to register itself as the ComputeCpp install on the machine.)
Anyhow, I was surprised to see that FindComputeCpp.cmake fails to find my install, even though I set -DComputeCpp_DIR=C:\Kellekek\Codeplay\ComputeCpp\2.11.0 on the CLI, the folder where the install is. It turns out, that because <packagename>_DIR is a special variable that controls the location of Package Config files, even though FindComputeCpp.cmake is a Find Module, inside the script, this variable is wiped.
CMakeLists.txt
message(STATUS "ComputeCpp_DIR: ${ComputeCpp_DIR}")
find_package(ComputeCpp REQUIRED)
FindComputeCpp.cmake
# Latest version of this file can be found at:
# https://github.com/codeplaysoftware/computecpp-sdk
message(STATUS "ComputeCpp_DIR: ${ComputeCpp_DIR}")
cmake_minimum_required(VERSION 3.10.2)
include(FindPackageHandleStandardArgs)
...
CLI output
C:\Kellekek\Kitware\CMake\3.24.0-rc4\bin\cmake.exe ... -DComputeCpp_DIR=C:\Kellekek\Codeplay\ComputeCpp\2.11.0 ...
...
-- ComputeCpp_DIR: C:\Kellekek\Codeplay\ComputeCpp\2.11.0
-- ComputeCpp_DIR: ComputeCpp_DIR-NOTFOUND
...
If I renamed the variable to anything else, such as ComputeCpp_DIRR it immediately worked. I tried looking for a CMake policy that changed this behavior, but I haven't found anything related to this, which is also supported by the fact that I get no warnings of implicitly falling back to OLD behavior of any policy. The result is the same even if ComputeCpp_DIR is a Cache variable.
My question is: has this ever worked? I suspect that this variable never worked and it was always the env var of the installer kicking in. I would suggest renaming it to something else.
IMHO
This variable would be better chosen to be ComputeCpp_ROOT. Even though that is a special variable name with an associated policy as of 3.12 it would be a future proof solution. Currently users have to ship FindComputeCpp.cmake alongside their app or clone the SDK along with installing the compiler and either way keep the two in sync. To make this work with the fix and in the future, users need to add the SDK cmake/Modules folder to CMAKE_MODULE_PATH as well as add set ComputeCpp_ROOT so that both the Find Module succeeds and it finds the compiler.
Even if the compiler would ship a matching Find Module, or better move to a Package Config script, this scenario will work, and current CLI invocations will pick up the easier to update SDK script. If the SDK is absent, whatever ships with the compiler will be picked up. Future proof, fool proof, backwards compatible solution.
Hi @MathiasMagnus,
I read this documentation years ago, but I do remember that xxxx_DIR was searched when looking for the package. It's possible that there's a conflict now as I believe ComputeCpp has started shipping a ComputeCpp-config.cmake file, though the contents are effectively the same as the find module. Can you try a comparison with an older ComputeCpp that doesn't have this file? I don't know what version that would be, maybe 2.9.
It's possible that this _ROOT variable is now the best choice, though it wasn't really a thing when we wrote this. Our intention was that the usage here should mirror other packages, regardless of whether the user was using a find module or a config file.
I have actually unset the environment variable on various of my machines (it was causing conflicts in unfortunate circumstances so I ditched it). I don't think therefore that it's only working because of the environment variable.
I believe ComputeCpp has started shipping a ComputeCpp-config.cmake file
Has it? There are 0 *.cmake files in the ComputeCpp install folder
gci C:\Kellekek\Codeplay\ComputeCpp\2.11.0\ -rec -fil *.cmake | measure | select -exp Count
0
Really? I have one:
duncan:computecpp-cmake-stuff$ ll ComputeCpp-experimental-CE-2.11.0-x86_64-linux-gnu
total 164K
drwxrwxr-x 2 duncan duncan 4.0K Aug 8 17:47 bin/
-rw-r--r-- 1 duncan duncan 21K Aug 8 17:38 ComputeCppConfig.cmake
drwxrwxr-x 3 duncan duncan 4.0K Aug 8 19:00 doc/
... other files
I assumed that the Windows package had the same files. Maybe not. I've just checked with a package I downloaded from the website, version 2.11.0. That being said, I also tried building a fresh build of the SDK with ComputeCpp_DIR set to the ComputeCpp I just downloaded, and I didn't get any conflicts, with the following output:
duncan:sdk-build$ cmake $HOME/computecpp-cmake-stuff/computecpp-sdk -GNinja -DComputeCpp_DIR=$HOME/computecpp-cmake-stuff/ComputeCpp-experimental-CE-2.11.0-x86_64-linux-gnu
... normal CMake output ...
-- Found OpenCL: /usr/lib/x86_64-linux-gnu/libOpenCL.so (found version "2.2")
-- platform - your system can support ComputeCpp
-- Found ComputeCpp: /home/duncan/computecpp-cmake-stuff/ComputeCpp-experimental-CE-2.11.0-x86_64-linux-gnu (found version "CE 2.11.0 2022/08/08")
-- compute++ flags - -O2;-mllvm;-inline-threshold=1000;-DSYCL_LANGUAGE_VERSION=2017
-- Configuring done
-- Generating done
-- Build files have been written to: /home/duncan/computecpp-cmake-stuff/sdk-build
I've been able to confirm that in my case there appears to be no conflict, and it uses the FindComputeCpp.cmake in the SDK, instead of the one shipped with the package (I made a modification which was picked up by CMake).
All that being said, I'm not really sure what's going on in your case. Could it be CMake behaviour differences between Windows and *NIX?
Until I figure out how I got to the point where I've seen the above mishap, I'm gonna go and close this issue. (I showed everything to a colleague just to make sure I'm not doing something irrational.) While I can't reproduce the issue, and since then I have forgotten whether the snippets posted were sanitized output from VS Code and CMake Tools (and I have come across mild annoyance of CMAKE_PREFIX_PATH not being inherited as expected), it may have been some variation of that.