+
+The OpenGL Extension Wrangler Library
+
+
+
+
+Automatic Code Generation
+
+
+Starting from release 1.1.0, the source code and parts of the
+documentation are automatically generated from the extension
+specifications in a two-step process. In the first step,
+specification files from the OpenGL registry are downloaded and
+parsed. Skeleton descriptors are created for each extension. These
+descriptors contain all necessary information for creating the source
+code and documentation in a simple and compact format, including the
+name of the extension, url link to the specification, tokens, function
+declarations, typedefs and struct definitions. In the second step,
+the header files as well as the library and glewinfo source are
+generated from the descriptor files. The code generation scripts are
+located in the auto subdirectory.
+
+
+
+The code generation scripts require GNU make, wget, and perl. On
+Windows, the simplest way to get access to these tools is to install
+Cygwin, but make sure that the
+root directory is mounted in binary mode. The makefile in the
+auto directory provides the following build targets:
+
+
+
+
+| make |
+ |
+Create the source files from the descriptors. If the
+descriptors do not exist, create them from the spec files. If the spec
+files do not exist, download them from the OpenGL repository. |
+| make clean |
+ |
+Delete the source files. |
+| make clobber |
+ |
+Delete the source files and the descriptors. |
+| make destroy |
+ |
+Delete the source files, the descriptors, and the spec files. |
+| make custom |
+ |
+Create the source files for the extensions
+listed in auto/custom.txt. See "Custom Code
+Generation" below for more details. |
+
+
+
+Adding a New Extension
+
+
+To add a new extension, create a descriptor file for the extension in
+auto/core and rerun the code generation scripts by typing
+make clean; make in the auto directory.
+
+
+
+The format of the descriptor file is given below. Items in
+brackets are optional.
+
+
+
+<Extension Name>
+[<URL of Specification File>]
+ [<Token Name> <Token Value>]
+ [<Token Name> <Token Value>]
+ ...
+ [<Typedef>]
+ [<Typedef>]
+ ...
+ [<Function Signature>]
+ [<Function Signature>]
+ ...
+
+
+
+
+
+
+Take a look at one of the files in auto/core for an
+example. Note that typedefs and function signatures should not be
+terminated with a semicolon.
+
+
+Custom Code Generation
+
+Starting from GLEW 1.3.0, it is possible to control which extensions
+to include in the libarary by specifying a list in
+auto/custom.txt. This is useful when you do not need all the
+extensions and would like to reduce the size of the source files.
+Type make clean; make custom in the auto directory
+to rerun the scripts with the custom list of extensions.
+
+
+
+For example, the following is the list of extensions needed to get GLEW and the
+utilities to compile.
+
+
+
+WGL_ARB_extensions_string
+WGL_ARB_multisample
+WGL_ARB_pixel_format
+WGL_ARB_pbuffer
+WGL_EXT_extensions_string
+WGL_ATI_pixel_format_float
+WGL_NV_float_buffer
+
+
+Multiple Rendering Contexts (GLEW MX)
+
+Starting with release 1.2.0, thread-safe support for multiple
+rendering contexts, possibly with different capabilities, is
+available. Since this is not required by most users, it is not added
+to the binary releases to maintain compatibility between different
+versions. To include multi-context support, you have to do the
+following:
+
+- Compile and use GLEW with the GLEW_MX preprocessor token
+defined.
+- For each rendering context, create a GLEWContext object
+that will be available as long as the rendering context exists.
+- Define a macro or function called glewGetContext() that
+returns a pointer to the GLEWContext object associated with
+the rendering context from which OpenGL/WGL/GLX calls are issued. This
+dispatch mechanism is primitive, but generic.
+
- Make sure that you call glewInit() after creating the
+GLEWContext object in each rendering context. Note, that the
+GLEWContext pointer returned by glewGetContext() has
+to reside in global or thread-local memory.
+
+
+Note that according to the MSDN
+WGL documentation, you have to initialize the entry points for
+every rendering context that use pixel formats with different
+capabilities For example, the pixel formats provided by the generic
+software OpenGL implementation by Microsoft vs. the hardware
+accelerated pixel formats have different capabilities. GLEW by
+default ignores this requirement, and does not define per-context
+entry points (you can however do this using the steps described
+above). Assuming a global namespace for the entry points works in
+most situations, because typically all hardware accelerated pixel
+formats provide the same entry points and capabilities. This means
+that unless you use the multi-context version of GLEW, you need to
+call glewInit() only once in your program, or more precisely,
+once per process.
+
+Separate Namespace
+
+
+To avoid name clashes when linking with libraries that include the
+same symbols, extension entry points are declared in a separate
+namespace (release 1.1.0 and up). This is achieved by aliasing OpenGL
+function names to their GLEW equivalents. For instance,
+glFancyFunction is simply an alias to
+glewFancyFunction. The separate namespace does not effect
+token and function pointer definitions.
+
+
+Known Issues
+
+
+GLEW requires GLX 1.2 for compatibility with GLUT.
+
+
+
+ | 
