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>
This commit is contained in:
Brian Paul
2015-05-25 09:13:09 -06:00
parent eec904d29c
commit 98f2f47f7a

View File

@@ -17,55 +17,15 @@
<h1>Development Notes</h1> <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> <ul>
<li> <li><a href="#style">Coding Style</a>
If glext.h doesn't define the extension, edit include/GL/gl.h and add <li><a href="#submitting">Submitting Patches</a>
code like this: <li><a href="#release">Making a New Mesa Release</a>
<pre> <li><a href="#extensions">Adding Extensions</a>
#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> </ul>
<h2 id="style">Coding Style</h2>
<h2>Coding Style</h2>
<p> <p>
Mesa's code style has changed over the years. Here's the latest. 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. src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as examples.
</p> </p>
<h2>Submitting patches</h2>
<h2 id="submitting">Submitting patches</h2>
<p> <p>
You should always run the Mesa Testsuite before submitting patches. 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. it harder for reviewers to accidentally review old patches.
</p> </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> <p>
If you want a commit to be applied to a stable branch, 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> <a href="http://cworth.org/~cworth/mesa-stable-queue/">Mesa Stable Queue</a>
page. 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 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 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> regression that is unaacceptable for the stable branch.</li>
</ul> </ul>
<h2>Making a New Mesa Release</h2>
<h2 id="release">Making a New Mesa Release</h2>
<p> <p>
These are the instructions for making a new Mesa release. These are the instructions for making a new Mesa release.
@@ -543,6 +505,56 @@ release announcement:
</pre> </pre>
</p> </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> </div>
</body> </body>
</html> </html>