ValveSoftware/vogl — pull request #176 by refnum (2014-11-14 21:59:42+00:00)
Title: Preliminary Mac OS X support

Hi,

This adds some preliminary support for Mac OS X. It is not yet able to capture a trace, even from glxspheres, however everything can now compile and link.

The trace library exports enough of OpenGL.framework for simple test apps like glxspheres to launch. They will crash once we reach some unimplemented code, however the trace library is inserted into the process and has started logging.

The next steps for Mac OS X support are to fill in some of that unimplemented code and generate a full cgl.spec definition, but this seems like a good point to try get something merged.

8ca31d8 is possibly the only non-obvious change. Apple's OpenGL implementation is a single framework that exports both CGLxxx symbols (Mac-specific GL APIs) and gluXXXX symbols. voglgen normally sets the prefix for a .spec file's symbols in the code however to support two prefixes from one .spec file this has been relaxed to allow the category in the .spec file to override the default prefix from voglgen.cpp.

If this approach seems sensible then voglgen.cpp can be simplified a bit by always using the category (essentially the function's calculated "full name") rather than passing function prefixes down to the generators.

The commit prints out any functions whose category doesn't match the supplied prefix and on Mac OS X/Linux the only examples that fire are the gluXXX symbols (i.e., all of the existing .spec files are compatible with this approach, as the in-code prefixes are essentially duplicating the prefix from the category).

If the category isn't the correct token to drive this then we could have an explicit 'prefix' token. This would require some changes to the .spec files but they would be fairly minimal (cgl.spec is the only file that would need something other than a global default).

Another approach might be to have a glut.spec which could define glut symbols (which would be exported on the Mac and not exported on other platforms). That means adding a fifth variant to the existing gl/glx/cgl/wgl set of types/code paths so this approach might be overkill.

Let me know if you'd like this broken down into a pull request per commit or similar.