summaryrefslogtreecommitdiffstats
path: root/docs/devinfo.html
diff options
context:
space:
mode:
authorBrian Paul <brianp@vmware.com>2015-05-25 09:13:09 -0600
committerBrian Paul <brianp@vmware.com>2015-05-26 10:02:59 -0600
commit98f2f47f7a1d893bb482d508a690c417c2453c6e (patch)
tree74e268d2152544e9abfb0f0e3b095df3ddefb595 /docs/devinfo.html
parenteec904d29c0d996fb05f24771a2fdd33e152f519 (diff)
downloadexternal_mesa3d-98f2f47f7a1d893bb482d508a690c417c2453c6e.zip
external_mesa3d-98f2f47f7a1d893bb482d508a690c417c2453c6e.tar.gz
external_mesa3d-98f2f47f7a1d893bb482d508a690c417c2453c6e.tar.bz2
docs: reorganize devnotes.html file
Move "Adding Extensions" to the end. Add a simple table of contents at the top. Reviewed-by: Thomas Helland <thomashelland90@gmail.com>
Diffstat (limited to 'docs/devinfo.html')
-rw-r--r--docs/devinfo.html110
1 files changed, 61 insertions, 49 deletions
diff --git a/docs/devinfo.html b/docs/devinfo.html
index 8d20eea..c7e4171 100644
--- a/docs/devinfo.html
+++ b/docs/devinfo.html
@@ -17,55 +17,15 @@
<h1>Development Notes</h1>
-<h2>Adding Extensions</h2>
-
-<p>
-To add a new GL extension to Mesa you have to do at least the following.
-
<ul>
-<li>
- If glext.h doesn't define the extension, edit include/GL/gl.h and add
- code like this:
- <pre>
- #ifndef GL_EXT_the_extension_name
- #define GL_EXT_the_extension_name 1
- /* declare the new enum tokens */
- /* prototype the new functions */
- /* TYPEDEFS for the new functions */
- #endif
- </pre>
-</li>
-<li>
- In the src/mapi/glapi/gen/ directory, add the new extension functions and
- enums to the gl_API.xml file.
- Then, a bunch of source files must be regenerated by executing the
- corresponding Python scripts.
-</li>
-<li>
- Add a new entry to the <code>gl_extensions</code> struct in mtypes.h
-</li>
-<li>
- Update the <code>extensions.c</code> file.
-</li>
-<li>
- From this point, the best way to proceed is to find another extension,
- similar to the new one, that's already implemented in Mesa and use it
- as an example.
-</li>
-<li>
- If the new extension adds new GL state, the functions in get.c, enable.c
- and attrib.c will most likely require new code.
-</li>
-<li>
- The dispatch tests check_table.cpp and dispatch_sanity.cpp
- should be updated with details about the new extensions functions. These
- tests are run using 'make check'
-</li>
+<li><a href="#style">Coding Style</a>
+<li><a href="#submitting">Submitting Patches</a>
+<li><a href="#release">Making a New Mesa Release</a>
+<li><a href="#extensions">Adding Extensions</a>
</ul>
-
-<h2>Coding Style</h2>
+<h2 id="style">Coding Style</h2>
<p>
Mesa's code style has changed over the years. Here's the latest.
@@ -160,7 +120,8 @@ of <tt>bool</tt>, <tt>true</tt>, and
src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as examples.
</p>
-<h2>Submitting patches</h2>
+
+<h2 id="submitting">Submitting patches</h2>
<p>
You should always run the Mesa Testsuite before submitting patches.
@@ -184,7 +145,7 @@ re-sending the whole series). Using --in-reply-to makes
it harder for reviewers to accidentally review old patches.
</p>
-<h2>Marking a commit as a candidate for a stable branch</h2>
+<h3>Marking a commit as a candidate for a stable branch</h3>
<p>
If you want a commit to be applied to a stable branch,
@@ -221,7 +182,7 @@ the upcoming stable release can always be seen on the
<a href="http://cworth.org/~cworth/mesa-stable-queue/">Mesa Stable Queue</a>
page.
-<h2>Criteria for accepting patches to the stable branch</h2>
+<h3>Criteria for accepting patches to the stable branch</h3>
Mesa has a designated release manager for each stable branch, and the release
manager is the only developer that should be pushing changes to these
@@ -306,7 +267,8 @@ be rejected:
regression that is unaacceptable for the stable branch.</li>
</ul>
-<h2>Making a New Mesa Release</h2>
+
+<h2 id="release">Making a New Mesa Release</h2>
<p>
These are the instructions for making a new Mesa release.
@@ -543,6 +505,56 @@ release announcement:
</pre>
</p>
+
+<h2 id="extensions">Adding Extensions</h2>
+
+<p>
+To add a new GL extension to Mesa you have to do at least the following.
+
+<ul>
+<li>
+ If glext.h doesn't define the extension, edit include/GL/gl.h and add
+ code like this:
+ <pre>
+ #ifndef GL_EXT_the_extension_name
+ #define GL_EXT_the_extension_name 1
+ /* declare the new enum tokens */
+ /* prototype the new functions */
+ /* TYPEDEFS for the new functions */
+ #endif
+ </pre>
+</li>
+<li>
+ In the src/mapi/glapi/gen/ directory, add the new extension functions and
+ enums to the gl_API.xml file.
+ Then, a bunch of source files must be regenerated by executing the
+ corresponding Python scripts.
+</li>
+<li>
+ Add a new entry to the <code>gl_extensions</code> struct in mtypes.h
+</li>
+<li>
+ Update the <code>extensions.c</code> file.
+</li>
+<li>
+ From this point, the best way to proceed is to find another extension,
+ similar to the new one, that's already implemented in Mesa and use it
+ as an example.
+</li>
+<li>
+ If the new extension adds new GL state, the functions in get.c, enable.c
+ and attrib.c will most likely require new code.
+</li>
+<li>
+ The dispatch tests check_table.cpp and dispatch_sanity.cpp
+ should be updated with details about the new extensions functions. These
+ tests are run using 'make check'
+</li>
+</ul>
+
+
+
+
</div>
</body>
</html>