OpenGL-Raw generator

Hello, 0123456789012345678901234567890123456789012345678901234567890123456789012 OpenGL Raw is still 'stuck' at version 3.2 of the OpenGL Specification. Updating it to a more recent version (including adding more extensions) is quite a task, and quite boring one too. Fortunately there are specifications [1] which specifies all the functions and enumeration values. As a possible solution I've created a generator to generate the most of the OpenGLRaw, including the most boring parts. The code has (finally) been uploaded to Github and can be found at [2]. The current situation is that it's almost undocumented and there are no options yet (every path, etc. is hard-coded). The current implementation (the develop branch) generates the following, * Enum values and functions in line with the Spec files of OpenGL, where for each category in the spec there is a corresponding module. * Several grouping modules which group the previously modules in to logical groups. The current implementation groups it into vendor modules (with all extension from that vendor), and ones for the core profiles. * A list of all the modules generated, in a format that can be used to make the cabal file. Most of the base things (loading proc addresses, the bare cabal file, the types) are reused for building the generated files. The biggest change from OpenGLRaw is the layout of modules which define the core of OpenGL. Raw has two modules (which get bundled) for defining all enums and functions up to GL3.1. While the generator groups them into modules by the spec version they were introduced, and makes an export for each module. Furthermore, the use of the CPP to make the foreign imports has abandoned as this wasn't really practical with haskell-src-exts. For those who are interested in building it, the major non-hackage dependencies are: * opengl-api, [3], A package by Vo Minh Thu to parse the OpenGL spec files, you need the head of develop to parse the current specs. * CodeGenerating, A package I made with all sorts of more generic functions used to generate haskell code, based on haskell-src-exts. Again take the head of develop for all the functions needed. If you would just like the output of it all without the hassle of building it, send email me for an archive. I hope this tool could be made of use in updating the OpenGLRaw package, as I currently see nobody doing it by hand. So if you have any question or comment about the tool please email me. Greetings, Lars [1] http://www.opengl.org/registry/#specfiles [2] https://github.com/Laar/OpenGLRawgen [3] https://github.com/Laar/opengl-api/tree/develop [4] https://github.com/Laar/CodeGenerating/tree/develop

I haven't look at it yet, but this sounds like exactly what I've been wanting. Thanks for sharing it! I think some ideas had been tossed around to do exactly this, but I don't think anything ever came of them. - Jake

On Thu, Dec 8, 2011 at 1:55 AM, Jake McArthur
I haven't look at it yet, but this sounds like exactly what I've been wanting. Thanks for sharing it! I think some ideas had been tossed around to do exactly this, but I don't think anything ever came of them.
- Jake
Hello, I've documented almost all top level declarations in the OpenGLRawgen package. Furthermore, I've been moving around some modules. Hoping that this generator generate an alternative implementation for OpenGLRaw there is the question of breaking changes. My major questions on this subject are 1. What should be in the top ...Raw.hs, currently it houses all functions and enum values, should it remain that way? Especially considering that the current generator builds a set of about 400 modules. My personal preference would be to only export the latest OpenGL specification or something alike (and the export of GetProcAddress should be removed any way). 2. The core (thus the basic OpenGL Spec) functions and enums are now defined in Core31.Tokens and Core31.Functions with the compatibility values in ARB.Compatiblity.Tokens and ...Functions. Additionally there is a second module .Core31 to group them and there exists Core32 which is Core31 + some extra re-exported extensions. This splitting (of functions and enums) and combining (of several core versions) is not that good for a generator. Additionally there is some extra information that could be used to generate modules for each version of the OpenGL spec. Thus the question arises how much of the current structure should be kept? Lars P.S. On the point of the core modules. The current state of the generator is that it creates modules ...Raw.Core.Internal.Core11 and ...Raw.Core.Internal.Core11Compatibility for each version of the spec containting all the FFI imports and enumValues. Furthermore it adds modules ...Raw.Core.Core31 which group the internal modules into all the definitions of a certain spec version. And for versions after 3.0 also a Compatibility module which also includes the deprecated functions and enums.

On Sun, Dec 11, 2011 at 4:44 PM, L Corbijn
1. What should be in the top ...Raw.hs, currently it houses all functions and enum values, should it remain that way? Especially considering that the current generator builds a set of about 400 modules. My personal preference would be to only export the latest OpenGL specification or something alike (and the export of GetProcAddress should be removed any way).
In my opinion, there just shouldn't be a top Raw.hs. The Core* modules are already there. I don't think it's too much of a burden to be explicit about what you want when using the package.
2. [...] Thus the question arises how much of the current structure should be kept?
I don't care much about backward compatibility, but others might. - Jake
participants (2)
-
Jake McArthur
-
L Corbijn