[HOpenGL] OpenGL-Raw generator

L Corbijn aspergesoepje at gmail.com
Sun Dec 11 22:44:51 CET 2011


On Thu, Dec 8, 2011 at 1:55 AM, Jake McArthur <jake.mcarthur at gmail.com> wrote:
> 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.



More information about the HOpenGL mailing list