Older revisions created a symlink for cl.hpp. I can not find an explanation for why this was dropped but typical C++ OpenCL applications include "CL/cl.hpp" so this breaks them. Reproducible: Always
Jan, is this still a problem?
(In reply to Matt Turner from comment #1) > Jan, is this still a problem? I've never run into this, but it looks like it's still a problem: > $ ls /usr/include/CL > cl_egl.h cl_ext.h cl_gl_ext.h cl_gl.h cl.h cl_platform.h opencl.h at least ocl-icd does not provide cl.hpp: > $ ls /usr/lib64/OpenCL/vendors/ocl-icd/include/CL/ > cl_d3d10.h cl_dx9_media_sharing.h cl_ext.h cl_gl.h cl_platform.h > cl_d3d11.h cl_egl.h cl_gl_ext.h cl.h opencl.h and eselect-opencl only provides cl.hpp for OCL 2.1: > $ ls /usr/lib64/OpenCL/global/include/* > /usr/lib64/OpenCL/global/include/CL-1.0: > cl_ext.h cl_gl_ext.h cl_gl.h cl.h cl_platform.h opencl.h > > /usr/lib64/OpenCL/global/include/CL-1.1: > cl_ext.h cl_gl_ext.h cl_gl.h cl.h cl_platform.h opencl.h > > /usr/lib64/OpenCL/global/include/CL-1.2: > cl_egl.h cl_ext.h cl_gl_ext.h cl_gl.h cl.h cl_platform.h opencl.h > > /usr/lib64/OpenCL/global/include/CL-2.0: > cl_egl.h cl_ext.h cl_gl_ext.h cl_gl.h cl.h cl_platform.h opencl.h > > /usr/lib64/OpenCL/global/include/CL-2.1: > cl_egl.h cl_ext.h cl_gl_ext.h cl_gl.h cl.h cl.hpp cl_platform.h opencl.h I don't know when and how select-opencl decides to headers from /global/. Note that Khronos does not include cl.hpp in its headers https://github.com/KhronosGroup/OpenCL-Headers but in a separate project https://github.com/KhronosGroup/OpenCL-CLHPP we can patch ocl-icd (and all other ocl providers that miss the header) to provide cl.hpp. however, given that the c++ bindings are not a core part of ocl specs, perhaps we should add a new clhpp package that can provide the header on top of any OCL provider?
I think there's some history here that's significant but I don't know all of it. What I've gathered is many projects used to include specific versions of the OpenCL headers in their own source trees and it caused a lot of problems at the system level. Gentoo packaged them once in eselect-opencl and the global directory worked around a lot of those problems. Now, Khronos has version-independent headers broken out into repos for both C and C++. Many projects seem to have dropped their in-tree headers in favor of those repos. I'll expand on what Jan said and suggest that it may be time for Gentoo to re-evaluate packaging the headers in eselect-opencl and instead package them more like upstream.
(In reply to Daniel M. Weeks from comment #3) > I think there's some history here that's significant but I don't know all of > it. What I've gathered is many projects used to include specific versions of > the OpenCL headers in their own source trees and it caused a lot of problems > at the system level. Gentoo packaged them once in eselect-opencl and the > global directory worked around a lot of those problems. > > Now, Khronos has version-independent headers broken out into repos for both > C and C++. Many projects seem to have dropped their in-tree headers in favor > of those repos. I'll expand on what Jan said and suggest that it may be time > for Gentoo to re-evaluate packaging the headers in eselect-opencl and > instead package them more like upstream. thanks. I'm not sure where that leaves us. Is anyone still maintaining eselect-opencl? should we: a) drop eselect-opencl and let ocl-icd provide khronos headers (including cl.hpp) b) drop eselect-opencl and let a separate package/s (dev-libs/opencl-headers, dev-libs/opencl-cpp-headers) provide ocl headers (including cl.hpp). virtual/opencl and dev-libs/ocl-icd can depend on those. c) keep eselect-opencl and fix it to provide khronos headers unless there is an ocl (loader) provider that includes custom headers (possibly with vendor specific extensions)
(In reply to Jan Vesely from comment #4) > (In reply to Daniel M. Weeks from comment #3) > > I think there's some history here that's significant but I don't know all of > > it. What I've gathered is many projects used to include specific versions of > > the OpenCL headers in their own source trees and it caused a lot of problems > > at the system level. Gentoo packaged them once in eselect-opencl and the > > global directory worked around a lot of those problems. > > > > Now, Khronos has version-independent headers broken out into repos for both > > C and C++. Many projects seem to have dropped their in-tree headers in favor > > of those repos. I'll expand on what Jan said and suggest that it may be time > > for Gentoo to re-evaluate packaging the headers in eselect-opencl and > > instead package them more like upstream. > > thanks. I'm not sure where that leaves us. Is anyone still maintaining > eselect-opencl? No, I don't think so. Getting rid of it and using ocl-icd is best. > should we: > a) drop eselect-opencl and let ocl-icd provide khronos headers (including > cl.hpp) > b) drop eselect-opencl and let a separate package/s > (dev-libs/opencl-headers, dev-libs/opencl-cpp-headers) provide ocl headers > (including cl.hpp). virtual/opencl and dev-libs/ocl-icd can depend on those. Dropping eselect-opencl seems best. I don't have a preference on whether ocl-icd provides the headers. I assume opencl headers don't change very often, so providing the headers in ocl-icd seems okay. If they do change relatively often, a single separate package would be good. I don't see the need for separate c/c++ header packages.
Created attachment 555680 [details] clhpp-2.0.10.ebuild (In reply to Matt Turner from comment #5) > (In reply to Jan Vesely from comment #4) > > (In reply to Daniel M. Weeks from comment #3) > > > I think there's some history here that's significant but I don't know all of > > > it. What I've gathered is many projects used to include specific versions of > > > the OpenCL headers in their own source trees and it caused a lot of problems > > > at the system level. Gentoo packaged them once in eselect-opencl and the > > > global directory worked around a lot of those problems. > > > > > > Now, Khronos has version-independent headers broken out into repos for both > > > C and C++. Many projects seem to have dropped their in-tree headers in favor > > > of those repos. I'll expand on what Jan said and suggest that it may be time > > > for Gentoo to re-evaluate packaging the headers in eselect-opencl and > > > instead package them more like upstream. > > > > thanks. I'm not sure where that leaves us. Is anyone still maintaining > > eselect-opencl? > > No, I don't think so. Getting rid of it and using ocl-icd is best. > > > should we: > > a) drop eselect-opencl and let ocl-icd provide khronos headers (including > > cl.hpp) > > b) drop eselect-opencl and let a separate package/s > > (dev-libs/opencl-headers, dev-libs/opencl-cpp-headers) provide ocl headers > > (including cl.hpp). virtual/opencl and dev-libs/ocl-icd can depend on those. > > Dropping eselect-opencl seems best. I don't have a preference on whether > ocl-icd provides the headers. I assume opencl headers don't change very > often, so providing the headers in ocl-icd seems okay. If they do change > relatively often, a single separate package would be good. I don't see the > need for separate c/c++ header packages. I think it'd be easier to provide a clhpp package than trying to mix ocl-icd and Khronos OpenCL-CLHPP in one ebuild. Moreover, the build process should generate cl.hpp cl2.hpp to match the current CL headers. How does the attached ebuild (dev-libs/clhpp) look?
ping. any thought on the new clhpp package?
(In reply to Jan Vesely from comment #7) > ping. > > any thought on the new clhpp package? Oops, sorry this fell off my radar. The ebuild looks good. Want to make a pull request on github with this and whatever other changes are required?
(In reply to Matt Turner from comment #8) > (In reply to Jan Vesely from comment #7) > > ping. > > > > any thought on the new clhpp package? > > Oops, sorry this fell off my radar. The ebuild looks good. Want to make a > pull request on github with this and whatever other changes are required? https://github.com/gentoo/gentoo/pull/11827 I've checked that neither mesa nor beignet nor nvidia-drivers nor intel-ocl-sdk include these headers.
(In reply to Jan Vesely from comment #9) > (In reply to Matt Turner from comment #8) > > (In reply to Jan Vesely from comment #7) > > > ping. > > > > > > any thought on the new clhpp package? > > > > Oops, sorry this fell off my radar. The ebuild looks good. Want to make a > > pull request on github with this and whatever other changes are required? > > https://github.com/gentoo/gentoo/pull/11827 > > I've checked that neither mesa nor beignet nor nvidia-drivers nor > intel-ocl-sdk include these headers. Thank you. I've merged that PR.
Don't virtual/opencl should depend on dev-libs/clhpp?
(In reply to nE0sIghT from comment #11) > Don't virtual/opencl should depend on dev-libs/clhpp? Probably not by default, C++ headers are separate from OpenCL, but maybe it can add a cxx useflag