sort new extensions programmatically #236
Conversation
The generated extension headers maintained an ordered list of older extensions to minimize diffs with the non-generated extension headers, but there is no reason to require this for new extensions. If a new extension is not found in the list, sort it at the end automatically. Note, Khronos (KHR) extensions will also be sorted before multi-vendor (EXT) extensions, and before vendor extensions.
| index = orderedExtensions.index(name) | ||
| except ValueError: | ||
| if name.startswith('cl_khr'): | ||
| index = 10000 |
There was a problem hiding this comment.
What's the behaviour when the same index is returned multiple times? Are definitions for extensions ordered following the order in which they appear in the XML?
There was a problem hiding this comment.
I had to look this up. The sort is stable if they have the same key:
https://docs.python.org/3/howto/sorting.html#sort-stability-and-complex-sorts
However, the sort key is actually a tuple consisting of the index and the name, so the end result should be that the new extensions are ordered after the older manually ordered extensions and alphabetized. This is the order I'd like to see for all extensions eventually - see getExtensionSortKey_ideal below.
|
Merging as discussed in the September 12th teleconference. |
The generated extension headers maintained an ordered list of older extensions to minimize diffs with the non-generated extension headers, but there is no reason to require this for new extensions. If a new extension is not found in the list, sort it at the end automatically. Note, Khronos (KHR) extensions will also be sorted before multi-vendor (EXT) extensions, and before vendor extensions.