remove an old cl.hpp

[bashbaug]

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.

[lygstate]

@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

[bashbaug]

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:

1. We deprecated and eventually removed the "old" cl.hpp: https://github.com/KhronosGroup/OpenCL-CLHPP/pull/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.
2. We renamed the "new" cl2.hpp to opencl.hpp to clarify that it was not specific to OpenCL 2.0: https://github.com/KhronosGroup/OpenCL-CLHPP/pull/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 because opencl.hpp is not equivalent to cl.hpp.

[lygstate]

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:

1. 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.

2. We renamed the "new" cl2.hpp to opencl.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 because opencl.hpp is not equivalent to cl.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

[bashbaug]

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?