Closed bashbaug closed 2 years ago
@bashbaug How about create a stub file such as
//
// Copyright (c) 2020 The Khronos Group Inc.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
//
#include "opencl.hpp"
#pragma message("cl.hpp has been renamed to opencl.hpp to make it clear that it supports all versions of OpenCL. Please include CL/opencl.hpp directly.")
like https://github.com/KhronosGroup/OpenCL-CLHPP/blob/main/include/CL/cl2.hpp does
Hello! Would you want to add this to the OpenCL-CLHPP repo? I don't think it makes sense to add it here, especially without the opencl.hpp
file, and we want to keep all of the C++ binding header files in the OpenCL-CLHPP repo.
It's been a while, but as I recall we used to have two versions of the C++ bindings: an older version cl.hpp
and a newer cl2.hpp
. This naming was confusing though, because the number indicated "old" vs. "new" and did not indicate which OpenCL version(s) that each file supported. To (try to) fix this we did two things:
cl.hpp
: https://github.com/KhronosGroup/OpenCL-CLHPP/pull/100
cl.hpp
was encouraged to switch to the "new" cl2.hpp
instead, though it is not a drop-in replacement and some code changes may be required.cl2.hpp
to opencl.hpp
to clarify that it was not specific to OpenCL 2.0: https://github.com/KhronosGroup/OpenCL-CLHPP/pull/104
cl2.hpp
we added the stub file.cl.hpp
because opencl.hpp
is not equivalent to cl.hpp
.Hello! Would you want to add this to the OpenCL-CLHPP repo? I don't think it makes sense to add it here, especially without the
opencl.hpp
file, and we want to keep all of the C++ binding header files in the OpenCL-CLHPP repo.It's been a while, but as I recall we used to have two versions of the C++ bindings: an older version
cl.hpp
and a newercl2.hpp
. This naming was confusing though, because the number indicated "old" vs. "new" and did not indicate which OpenCL version(s) that each file supported. To (try to) fix this we did two things:
We deprecated and eventually removed the "old"
cl.hpp
: Remove deprecated cl.hpp OpenCL-CLHPP#100
- Code previously using the "old"
cl.hpp
was encouraged to switch to the "new"cl2.hpp
instead, though it is not a drop-in replacement and some code changes may be required.We renamed the "new"
cl2.hpp
toopencl.hpp
to clarify that it was not specific to OpenCL 2.0: Rename cl2.hpp to opencl.hpp OpenCL-CLHPP#104
- To maintain backwards compatibility with code including
cl2.hpp
we added the stub file.- We can't add a similar stub file for
cl.hpp
becauseopencl.hpp
is not equivalent tocl.hpp
.
I raised question is because of this https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19816 Is that mesa distribute old cl.hpp is a good idea? because upstream OpenCL-CLHPP already removed in repo
Is that mesa distribute old cl.hpp is a good idea?
It's tough for me to answer this question.
The old cl.hpp
should still work, so if you (or mesa) still has code that relies on it you may want to continue distributing it so this code continues to work. We've deprecated and removed the old cl.hpp
in favor of opencl.hpp
(which used to be cl2.hpp
) though, so it'd be best to switch to opencl.hpp
to take advantage of the latest bug fixes and features.
Does this help?
Removes an old version of the C++ bindings from this repo to reduce confusion.
The latest C++ bindings can be found on their own GitHub: https://github.com/KhronosGroup/OpenCL-CLHPP
Note that the registry webpage already links to the C++ bindings GitHub, and not to the removed file.