In #1 I touched upon the issue of how to present utilities from the SDK to the users.
The way I imagine the OpenCL SDK hosted by Khronos, is that it provides all the necessary files to compile an OpenCL application (the ICD loader and headers) as well as a utility library which applications could rely on to take care of some tedium in the API.
Consume via CMake
The way I imagined this was to extend the current CMake namespace with the SDK library. Applications consuming both sub-projects may do so via:
In #1 I touched upon the issue of how to present utilities from the SDK to the users.
The way I imagine the OpenCL SDK hosted by Khronos, is that it provides all the necessary files to compile an OpenCL application (the ICD loader and headers) as well as a utility library which applications could rely on to take care of some tedium in the API.
Consume via CMake
The way I imagined this was to extend the current CMake namespace with the SDK library. Applications consuming both sub-projects may do so via:
Utilities
Here is a short list of things I've grown to use in a few applications of mine.
profiling a la
std::chrono
implementation
Iterator-based entry point
This I would like to propose as well for
opencl.hpp
implementation
Obtain executable path
implementation