L Corbijn | 7 Dec 2011 22:10
Picon
Gravatar

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
(Continue reading)

Jake McArthur | 8 Dec 2011 01:55
Picon

Re: OpenGL-Raw generator

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
L Corbijn | 11 Dec 2011 22:44
Picon
Gravatar

Re: OpenGL-Raw generator

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
(Continue reading)

Jake McArthur | 12 Dec 2011 04:07
Picon

Re: OpenGL-Raw generator

On Sun, Dec 11, 2011 at 4:44 PM, L Corbijn <aspergesoepje <at> gmail.com> wrote:
> 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

Gmane