Synchronizing auto-generated files with bindings

[javagl]

(This came up as part of #880, but applies to all bindings, and may therefore warrant its own issue)

There are some files that seem to be largely auto-generated. One of them is vkFormat2glInternalFormat.inl.

These files usually have corresponding files in the bindings. For example

• KtxInternalFormat.java in the Java bindings
• gl_internalformat.py in the python bindings

As part of a general cleanup of the JNI part, I wanted to check whether these constants definitions are up to date. But

1. without knowing which files are auto-generated, it's hard to decide what has to be done manually
2. doing this manually for all bindings sounds like a maintenance nightmare

I already did it manually for things like KtxErrorCode.java, which contains few values, is not auto-generated in the source, and expected to change rarely. But for most of these constants, any manual approach seems infeasible. Just looking at the number of constants, there seem to be 195 cases in vkFormat2glInternalFormat.inl, but only 84 cases in KtxInternalFormat.java, and there doesn't seem to be a reasonable way to "sync" them manually.

Are there any ideas or preferred ways for updating these files?

(I've seen that, for example, the VkFormat.java already is auto-generated, but I'm not sure how well this would scale to the other files)

In doubt, I'll do an update of the files in the JNI bindings, based on the latest state, with some TextPad macros and helper scripts. But I'm wondering about a more future-proof solution.

[MarkCallow]

See BUILDING.md for documentation of the auto generated files. Most are generated currently from vulkan_core.h, three by a script in the KTX-Specification repo using the mapping database that is part of the spec. Work is underway to generate the VkFormat related files direct from the Vulkan registry but it is still early days. @javagl since you are a Khronos member you can view the related MR, !6495, in the Khronos GitLab.
Things like ktxErrorCode.java change rarely enough that it doesn't seem worth the trouble to set up auto-generation.

Files related to the defines for OpenGL formats, internalformats and types should ideally also be auto-generated. There is insufficient info in gl.h to identify which #defines are for which type of data. It may be possible to generate these from the OpenGL registry but on the other hand, since nothing new is being added to OpenGL, it isn't worth the trouble. Mind you I'd like to have glInternalformat2String and glError2String functions which we don't have because manually generating them is such a pain. There are useful for applications not so much for libktx.

[MarkCallow]

By the way the Java and Python internal format files are not related to vkFormat2glInternalFormat.inl. The first two are definitions of the OpenGL internal format constants. The last is a switch mapping VkFormat enum values to GL internal formats.