Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Representing conditional defines in the XML file #463

Closed
bashbaug opened this issue Sep 28, 2020 · 2 comments
Closed

Representing conditional defines in the XML file #463

bashbaug opened this issue Sep 28, 2020 · 2 comments

Comments

@bashbaug
Copy link
Contributor

There are a couple of places in the OpenCL extension headers where enums or types are conditionally defined. A few examples:

https://github.com/KhronosGroup/OpenCL-Headers/blob/master/CL/cl_ext.h#L32

#if CL_TARGET_OPENCL_VERSION <= 110
#define CL_DEVICE_DOUBLE_FP_CONFIG                       0x1032
#endif

https://github.com/KhronosGroup/OpenCL-Headers/blob/master/CL/cl_ext.h#L508

#if !defined(CL_VERSION_2_1)
/* For OpenCL 2.1 and newer, cl_kernel_sub_group_info is declared in CL.h.
   In hindsight, there should have been a khr suffix on this type for
   the extension, but keeping it un-suffixed to maintain backwards
   compatibility. */
typedef cl_uint             cl_kernel_sub_group_info;
#endif

What is the best way to represent these conditions in the XML file?

Tagging @oddhack since perhaps there is already a convention we can borrow from other XML files.

@oddhack
Copy link
Contributor

oddhack commented Sep 28, 2020

There isn't any existing schema for this. If I were doing this I'd approach it through the <require> tag. While that normally requires an API extension to support the features inside the tag, you could add an attribute for something like <require condition="CL_TARGET_OPENCL_VERSION <= 110"> and use that literal string in a generated preprocessor wrapper - or, if you needed the semantics of the condition to be comprehensible to an output generator, some more complex attribute grammar.

@bashbaug
Copy link
Contributor Author

bashbaug commented Nov 6, 2020

Closing for now - I'll reopen if something comes up in the review of #469.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants