mirror of
https://github.com/nigels-com/glew.git
synced 2025-10-30 12:02:23 +00:00
170 lines
6.8 KiB
HTML
170 lines
6.8 KiB
HTML
<h2>Automatic Code Generation</h2>
|
|
|
|
<p>
|
|
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 <tt>auto</tt> subdirectory.
|
|
</p>
|
|
|
|
<p>
|
|
The code generation scripts require GNU make, wget, and perl. On
|
|
Windows, the simplest way to get access to these tools is to install
|
|
<a href="http://www.cygwin.com/">Cygwin</a>, but make sure that the
|
|
root directory is mounted in binary mode. The makefile in the
|
|
<tt>auto</tt> directory provides the following build targets:
|
|
</p>
|
|
|
|
<table border=0 cellpadding=0 cellspacing=5>
|
|
<tr><td align="left" valign="top"><tt>make</tt></td>
|
|
<td align=left>Create the source files from the descriptors.<br/> If the
|
|
descriptors do not exist, create them from the spec files.<br/> If the spec
|
|
files do not exist, download them from the OpenGL repository.</td></tr>
|
|
<tr><td align="left" valign="top"><tt>make clean</tt></td>
|
|
<td align=left>Delete the source files.</td></tr>
|
|
<tr><td align="left" valign="top"><tt>make clobber</tt></td>
|
|
<td align=left>Delete the source files and the descriptors.</td></tr>
|
|
<tr><td align="left" valign="top"><tt>make destroy</tt></td>
|
|
<td align=left>Delete the source files, the descriptors, and the spec files.</td></tr>
|
|
<tr><td align="left" valign="top"><tt>make custom</tt></td>
|
|
<td align=left>Create the source files for the extensions
|
|
listed in <tt>auto/custom.txt</tt>.<br/> See "Custom Code
|
|
Generation" below for more details.</td></tr>
|
|
</table>
|
|
|
|
<h3>Adding a New Extension</h3>
|
|
|
|
<p>
|
|
To add a new extension, create a descriptor file for the extension in
|
|
<tt>auto/core</tt> and rerun the code generation scripts by typing
|
|
<tt>make clean; make</tt> in the <tt>auto</tt> directory.
|
|
</p>
|
|
|
|
<p>
|
|
The format of the descriptor file is given below. Items in
|
|
brackets are optional.
|
|
</p>
|
|
|
|
<p class="pre">
|
|
<Extension Name><br>
|
|
[<URL of Specification File>]<br>
|
|
[<Token Name> <Token Value>]<br>
|
|
[<Token Name> <Token Value>]<br>
|
|
...<br>
|
|
[<Typedef>]<br>
|
|
[<Typedef>]<br>
|
|
...<br>
|
|
[<Function Signature>]<br>
|
|
[<Function Signature>]<br>
|
|
...<br>
|
|
<!-- [<Function Definition>]<br>
|
|
[<Function Definition>]<br>
|
|
...<br> -->
|
|
</p>
|
|
|
|
<!--
|
|
<p>
|
|
Note that <tt>Function Definitions</tt> are copied to the header files
|
|
without changes and have to be terminated with a semicolon. In
|
|
contrast, <tt>Tokens</tt>, <tt>Function signatures</tt>, and
|
|
<tt>Typedefs</tt> should not be terminated with a semicolon.
|
|
</p>
|
|
-->
|
|
|
|
<p>
|
|
Take a look at one of the files in <tt>auto/core</tt> for an
|
|
example. Note that typedefs and function signatures should not be
|
|
terminated with a semicolon.
|
|
</p>
|
|
|
|
<h3>Custom Code Generation</h3>
|
|
<p>
|
|
Starting from GLEW 1.3.0, it is possible to control which extensions
|
|
to include in the libarary by specifying a list in
|
|
<tt>auto/custom.txt</tt>. This is useful when you do not need all the
|
|
extensions and would like to reduce the size of the source files.
|
|
Type <tt>make clean; make custom</tt> in the <tt>auto</tt> directory
|
|
to rerun the scripts with the custom list of extensions.
|
|
</p>
|
|
|
|
<p>
|
|
For example, the following is the list of extensions needed to get GLEW and the
|
|
utilities to compile.
|
|
</p>
|
|
|
|
<p class="pre">
|
|
WGL_ARB_extensions_string<br>
|
|
WGL_ARB_multisample<br>
|
|
WGL_ARB_pixel_format<br>
|
|
WGL_ARB_pbuffer<br>
|
|
WGL_EXT_extensions_string<br>
|
|
WGL_ATI_pixel_format_float<br>
|
|
WGL_NV_float_buffer<br>
|
|
</p>
|
|
|
|
<h2>Multiple Rendering Contexts (GLEW MX)</h2>
|
|
|
|
<p>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:</p>
|
|
<ol>
|
|
<li>Compile and use GLEW with the <tt>GLEW_MX</tt> preprocessor token
|
|
defined.</li>
|
|
<li>For each rendering context, create a <tt>GLEWContext</tt> object
|
|
that will be available as long as the rendering context exists.</li>
|
|
<li>Define a macro or function called <tt>glewGetContext()</tt> that
|
|
returns a pointer to the <tt>GLEWContext</tt> object associated with
|
|
the rendering context from which OpenGL/WGL/GLX calls are issued. This
|
|
dispatch mechanism is primitive, but generic.
|
|
<li>Make sure that you call <tt>glewInit()</tt> after creating the
|
|
<tt>GLEWContext</tt> object in each rendering context. Note, that the
|
|
<tt>GLEWContext</tt> pointer returned by <tt>glewGetContext()</tt> has
|
|
to reside in global or thread-local memory.
|
|
</ol>
|
|
|
|
<p>Note that according to the <a
|
|
href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/ntopnglr_6yer.asp">MSDN
|
|
WGL documentation</a>, 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. <b>GLEW by
|
|
default ignores this requirement, and does not define per-context
|
|
entry points (you can however do this using the steps described
|
|
above).</b> 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 <tt>glewInit()</tt> only once in your program, or more precisely,
|
|
once per process.</p>
|
|
|
|
<h2>Separate Namespace</h2>
|
|
|
|
<p>
|
|
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,
|
|
<tt>glFancyFunction</tt> is simply an alias to
|
|
<tt>glewFancyFunction</tt>. The separate namespace does not effect
|
|
token and function pointer definitions.
|
|
</p>
|
|
|
|
<h2>Known Issues</h2>
|
|
|
|
<p>
|
|
GLEW requires GLX 1.2 for compatibility with GLUT.
|
|
</p>
|
|
|