[XML] Version condition mismatch on CL_DEPTH

[SunSerega]

            <require condition="!defined(CL_VERSION_1_2)" comment="cl_channel_order - defined in CL.h for OpenCL 1.2 (?) and newer">
                <enum name="CL_DEPTH"/>
            </require>

But above, CL_DEPTH is added as part of the:

    <feature api="opencl" name="CL_VERSION_2_0" number="2.0" comment="OpenCL core API interface definitions">

Is it supposed to be so?

[bashbaug]

Note, there is some additional background here: #284 and here: #458. (edit: fixed PR link)

Also here: KhronosGroup/OpenCL-Headers#117

I think this problem really stems from the OpenCL headers and specifically cl.h, where we have:

#ifdef CL_VERSION_1_2
#define CL_DEPTH                                    0x10BD
#define CL_DEPTH_STENCIL                            0x10BE
#endif

IMHO there are two bugs here:

1. CL_DEPTH is in the core specification but it wasn't until added until OpenCL 2.0, so it should be guarded by CL_VERSION_2_0 and not CL_VERSION_1_2.
2. CL_DEPTH_STENCIL was never in the core specification (it's part of cl_khr_gl_depth_images), so it shouldn't be in cl.h at all.

We could fix this but there's a small chance it could break shipping code. For example, if an application was building for OpenCL 1.2, was including cl.h but not cl_ext.h (for CL_DEPTH) or cl_gl.h (for CL_DEPTH_STENCIL), and was using CL_DEPTH or CL_DEPTH_STENCIL, code could stop building.

Admittedly the chances of this happening seems small. Should we just fix this? Is the current behavior causing a problem or is it just confusing?

[SunSerega]

Note, there is some additional background here

You pasted the same issue link twice... I guess you meant associated PR?

Is the current behavior causing a problem or is it just confusing?

It didn't cause any problems for me personally.
Found while looking for other info - thought should probably report it.

[bashbaug]

You pasted the same issue link twice... I guess you meant associated PR?

Oops, thanks! Fixed.

Found while looking for other info - thought should probably report it.

Thank you, much appreciated.

I'll add a comment to my previous OpenCL-Headers issue and we'll see if we can get this fixed...