Commits

Jason McKesson committed a522c9f

Gave documentation more links.

Comments (0)

Files changed (4)

Command_Line_Options.wiki

 The code generation suite has a number of different ways of outputting the functions and enumerators that define OpenGL. This option allows the user to select between these particular mechanisms. It must be one of the following values:
 
 * {{{pointer_c}}}: default.
-The specific meaning of these parameters is explained elsewhere. Note that the system is designed to be extensible; new styles can be added by modifying an appropriate script and hooking it into the right place in {{{modules/Styles.lua}}}.
+The specific meaning of these parameters is [[Styles|explained elsewhere.]] Note that the system is designed to be user-extensible; new styles can be added by creating an appropriate script and hooking it into the right place in {{{modules/Styles.lua}}}.
 
 **-indent**:
 
 
 The above command line will generate {{{gl_core_3_3.h}}} and {{{gl_core_3_3.c}}} files. Simply include them in your project; there is no library to build, no unresolved extenals to filter through. They just work (Well, that's the plan ;) ).
 
+The [[Command_Line_Options|full command-line syntax documentation]] is available. The {{{-style}}} parameter's [[Styles|meaning is defined here]].
+
 ==Extensions==
 
 Note that the above command line will //only// generate enumerators and functions for core OpenGL 3.3. It doesn't offer any extensions. To use extensions, you must ask for them with command line parameters, as follows:

Style_Creation.wiki

+The style system is designed to be extensible and as simple as possible. That doesn't mean it's not somewhat complex.
-The {{{-style}}} command line option defines how the header and source files are generated. While the styles will have some differences, every style provides a common set of functionality (though exactly how it is exposed differs). Styles provide:
+The {{{-style}}} command line option defines how the header and source files are generated. They will always generate the same information (more or less); the difference between styles explains the form that this information takes. The information generated is:
 
 * Typedefs for OpenGL concepts (GLenum, etc).
 * A means to tell whether each of the extensions specified by the user is loaded or not. This is usually exposed via a global variable who's name contains the extension name.
 * The enumerators for all of the extensions specified as well as any specified OpenGL versions/profiles (where applicable).
 * Functions (whether function pointers or something else, that's up to the style) for the various extensions specified, as well as any specified OpenGL versions/profiles (where applicable).
-* A function that will load all function pointers. Even if the style requires static linking, it will still provide a special function to do this. Until this function is called, you cannot use any of the mechanisms to test whether an extension is loaded, nor can you call any other functions.\\The function's return value will be a status code saying whether it succeeded. Success is defined solely in terms of loading the specified core OpenGL version; therefore, WGL or GLX loader functions will always "succeed". Test for individual extensions if you want to know what happened there.
+* A function that will load all function pointers. Even if the style uses static linking, a function will still be provided. Until this function is called, you cannot use any of the mechanisms to test whether an extension is loaded, nor can you call any other functions.\\The function's return value will be a status code saying whether it succeeded. Success is defined solely in terms of loading the specified core OpenGL version; therefore, WGL or GLX loader functions will always "succeed". Test for individual extensions if you want to know what happened there.
 * Optionally, if using the OpenGL specification, the style will export a number of useful helper functions to query OpenGL version information. This is per-style.
 The different types of styles will decide what form these take (enumerators could be {{{const}}} variables of some kind instead of the usual {{{#define}}}s, for example). But each style must provide this set of information.
 
 This system cannot due that, primarily because the source of the OpenGL specification information (the .spec files, as processed through various scripts) does not provide enough information. The spec files only define what is core or compatibility in the current OpenGL version, not what //used// to be core for a while, then was only in compatibility, then came back into core.
 
 Therefore, the system errs on the side of being inclusive. If it came back into core, it is considered to have never //left// core OpenGL. Thus, if you ask the system for 3.1, core profiles, you will see {{{GL_QUADS}}}, as well as a few others. The number of these are rather few, so it should not be a problem.
+==Available styles==
+
+There are a number of styles available, with documentation explaining exactly what they generate:
+
+* {{{[[Style_Pointer_C|pointer_c]]}}}: Used for C-style header generation.
+
+==User-created styles==
+
+The style mechanism is designed to be extensible. You should be able to write new styles relatively painlessly. This system is [[Style_Creation|covered in some detail]]. The general idea is that you write a Lua script that exposes a number of functions. Then you hook this script into the build system by adding a line of code to one of the files. At which point, you're done. Making the style script is the hard part.