PDA

View Full Version : List of prototypes and #defines only for a specific version



mixedcase
07-26-2012, 10:11 AM
Are there any headers that only include the function prototypes and #defines/enums for a specific version of OpenGL? Say I want OpenGL 4.2. I want a list of those functions and values with nothing else included. Is there anything like that?

The documentation man pages seems to only include the entries for a specific version but that's not in a usable format (ie. headers). Plus these don't seem to list all the enum values in one place, they're scattered across all the individual pages and I'm not even sure they're all listed there either.

It seems to me that it would be good if I could define something like "USE_VERSION_4_2" before including the GL headers and then get only the stuff related to that version (this is appears impossible with the current headers).

The reason I want to do this is for connecting OpenGL to a scripting language. My choice is either to include anything and everything which is too much work for a bunch of stuff I'm not going to use, or somehow manually pick through all the prototypes to get just the version I want which is also an insane amount of work. Not to mention trying to find all the #define/enum's only for a specific version seems impossible because I have never seen a concise version specific list.

It seems like someone, somewhere should have created a version specific list of stuff, no?

Alfonse Reinheart
07-26-2012, 11:46 AM
You're kinda putting the cart before the horse. What the header includes is irrelevant, because you're trying to hook OpenGL directly into a scripting language. Which means you're going to need some kind of binding layer. So unless your binding layer actually parses C headers, you'd have to do manual work for each function.

What you should do is look into parsing the .spec files, which is the source of all headers. These are notoriously difficult to parse, but I have a project that does the hard part, providing an XML version of the .spec files. (https://bitbucket.org/alfonse/gl-xml-specs) You should be able to take these and use an automated tool to generate whatever you want. C headers, binding code for <insert scripting language here>, etc.

Indeed, it also comes with a Lua version of the specs (which I use as an intermediate to create the XML version), which if you know Lua, can make generating what you need much easier.

The GL Load library of the OpenGL SDK provides something kind-of what you're looking for. Each version, core and compatibility, has its own header which will not bring in functions from higher versions. It's built on the above parsing system, but there is an issue. Where this is less than useful for your needs is that it treats core extensions (http://www.opengl.org/wiki/Extension#Core_Extensions) as extensions, rather than core features. So it lumps them into the giant "include every extension" header.

This means that, for example, `_int_gl_4_0.h`, the header that contains only the functions and enums defined in GL 4.0 core, doesn't list anything from ARB_tessellation_shader, ARB_shader_subroutine, or any of the other core extensions that ship with GL 4.0. Indeed, there are no `_int_gl_4_1.h` or `_int_gl_4_2.h`, because such files would be empty; all of their functionality comes from core extensions.

I did it this way mainly for sanity's sake. I could have put the definitions in both and #defined around them so that only one would be included, but it was just as easy to stick them in one centralized place: put the extensions in the extension file.

So if you do have some header parsing system, this may be of limited utility to you. But the parsing method should be trivial.

mixedcase
07-26-2012, 12:33 PM
I do not need a binding layer because I'm using LuaJIT which has a direct FFI interface that can parse C headers.

I didn't know about the .spec files, that might be what I was looking for although I can't tell if they break out the functionality by OpenGL version or not. Does your spec-to-XML solution do that?

This all seems rather messy because I noticed while reading through the official documentation that it actually missing pieces too. I was looking at the 4.2 reference documentation and some functions that are not deprecated are not listed. The whole deprecation process seems very loose and ugly. Ugh... Maybe the .spec files are cleaner.

Alfonse Reinheart
07-26-2012, 01:11 PM
I do not need a binding layer because I'm using LuaJIT which has a direct FFI interface that can parse C headers.

Can it handle function pointers?

The .spec files contain much of the information needed to use the OpenGL functions, including classifying them by where the functions come from. The XML files are just an XML-ized form of the .spec format; this makes it easier to parse, as parsing the .spec "format" isn't the simplest thing in the world.


I was looking at the 4.2 reference documentation and some functions that are not deprecated are not listed.

Such as? Remember: the docs often combine parameter-specific variants (what would be overloads in C++) into one function.

mixedcase
07-26-2012, 02:27 PM
Can it handle function pointers?

It handles anything. If you're a Lua user I'm surprised you don't know about LuaJIT (http://luajit.org). It is probably the best scripting system ever created. The FFI interface is the fastest most functional of anything I have seen too. No more writing native bindings. ;)


The .spec files contain much of the information needed to use the OpenGL functions, including classifying them by where the functions come from. The XML files are just an XML-ized form of the .spec format; this makes it easier to parse, as parsing the .spec "format" isn't the simplest thing in the world.

Alright, I'll take a look at this and see what I can do. There does seem to be some version information but it seems like almost everything is designed around including the whole spec, plus the kitchen sink. :) It's hard to tell which functions and values go with which versions of OpenGL because it's a giant mash of old and new with no clear separation. I hope it's buried in those spec files.


Such as? Remember: the docs often combine parameter-specific variants (what would be overloads in C++) into one function.

I deleted all the work I did trying to go down that path so I'm not sure now. It was probably just my parsing or something else wrong. Scraping prototypes from web pages is a pretty poor solution. Doesn't really matter now, trying to use those docs to create prototypes is a waste of time since the .spec files should be better.

Alfonse Reinheart
07-26-2012, 02:46 PM
It handles anything. If you're a Lua user I'm surprised you don't know about LuaJIT. It is probably the best scripting system ever created. The FFI interface is the fastest most functional of anything I have seen too. No more writing native bindings.

Unless, you know, you're a C++ programmer. In which case it's useless.


It's hard to tell which functions and values go with which versions of OpenGL because it's a giant mash of old and new with no clear separation. I hope it's buried in those spec files.

The functions are simple, as they clearly state in the function definitions where each function comes from. What extensions and GL versions they're associated with.

Enumerators are not so well defined. Indeed, enums have no version information at all, and the information about which enums can be used by which functions is so out of date that it's misleading.

mixedcase
07-26-2012, 03:16 PM
Unless, you know, you're a C++ programmer. In which case it's useless.

Hardly, it's possible to call C++ through the FFI (check the mailing list). C++ header parsing is being considered but is a non-trivial problem. Not completely useless though.

I write C++ all day and find Lua perfectly functional.


The functions are simple, as they clearly state in the function definitions where each function comes from. What extensions and GL versions they're associated with.

Enumerators are not so well defined. Indeed, enums have no version information at all, and the information about which enums can be used by which functions is so out of date that it's misleading.

Yeah, the enumerations and other values make me want to just include everything because it's too much work to figure it out. I suppose including just the 4.2 functions and all the enumerations is the closest I can easily get.