Ben Ashbaugh

Excellent, that's encouraging. I added a "requirements.txt" - good suggestion, thanks! This has been a "draft" for a month and a half now, so it's probably ready for a review...

> I think maintaining coherency through the project is important. Yeah, I agree, that's one of the key benefits of generating these headers vs. authoring them manually. It's easy to...

> Shouldn't only functions that can be linked against have a formal declaration in the headers? This is a very good question. I think it depends how we expect the...

> I am very curious about b. Do you have a lightweight strategy in mind to achieve this? I assume you could hash by the dispatch table/it's first entry, but...

I have a few updates related to this PR: 1. I added the `CL_NO_PROTOTYPES` change described above so it is easy to have the function pointer typedefs only but not...

We've been using these scripts to generate headers for most new extensions and it seems to be working well. It would be great to merge this PR to improve consistency...

A few notes about possible issues where code could break after merging these changes, in case there are clever ideas how to solve these or at least so we can...

Do you have a feel for what this would look like? I think we could use each of the enums fairly easily: ```c void use_all_enums() { (void)CL_ENUM_XXX; (void)CL_ENUM_YYY; } ```...

FWIW, we used to have alignment attributes on these types, but removed them a couple of years ago: https://github.com/KhronosGroup/OpenCL-Headers/pull/40 The POCL issue linked above seems to be about passing structs...

Thank you for your patience and sorry for the slow reply. I'm not sure that there is a "right answer" to this problem. On the one hand, including the alignment...