Development Notes
-Development Notes
- -Adding Extentions
+Adding Extentions
To add a new GL extension to Mesa you have to do at least the following. @@ -28,7 +36,7 @@ To add a new GL extension to Mesa you have to do at least the following.
Coding Style
+Coding Style
Mesa's code style has changed over the years. Here's the latest. @@ -71,6 +79,13 @@ well documented. Also, strive to write clean, easily understandable code. If you use tabs, set them to 8 columns
++Line width: the preferred width to fill comments and code in Mesa is 78 +columns. Exceptions are sometimes made for clarity (e.g. tabular data is +sometimes filled to a much larger width so that extraneous carriage returns +don't obscure the table). +
+Brace example:
@@ -81,10 +96,26 @@ Brace example: else { bar; } + + switch (condition) { + case 0: + foo(); + break; + + case 1: { + ... + break; + } + + default: + ... + break; + }Here's the GNU indent command which will best approximate my preferred style: +(Note that it won't format switch statements in the preferred way)
indent -br -i3 -npcs --no-tabs infile.c -o outfile.c @@ -114,68 +145,109 @@ Function name examples: _mesa_foo_bar() - an internal non-static Mesa function+
+Places that are not directly visible to the GL API should prefer the use +of bool, true, and +false over GLboolean, GL_TRUE, and +GL_FALSE. In C code, this may mean that +#include <stdbool.h> needs to be added. The +try_emit_* methods in src/mesa/program/ir_to_mesa.cpp and +src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as examples. +
-Making a New Mesa Release
+Submitting patches
-These are the instructions for making a new Mesa release. +You should always run the Mesa Testsuite before submitting patches. +The Testsuite can be run using the 'make check' command. All tests +must pass before patches will be accepted, this may mean you have +to update the tests themselves.
-Get latest source files
-Use git to get the latest Mesa files from the git repository, from whatever -branch is relevant. +Patches should be sent to the Mesa mailing list for review. +When submitting a patch make sure to use git send-email rather than attaching +patches to emails. Sending patches as attachments prevents people from being +able to provide in-line review comments.
++When submitting follow-up patches you can use --in-reply-to to make v2, v3, +etc patches show up as replies to the originals. This usually works well +when you're sending out updates to individual patches (as opposed to +re-sending the whole series). Using --in-reply-to makes +it harder for reviewers to accidentally review old patches. +
+ +Marking a commit as a candidate for a stable branch
-Verify and update version info
-Create/edit the docs/relnotes-x.y.html file to document what's new in the release. -Add the new relnotes-x.y.html file to relnotes.html. +If you want a commit to be applied to a stable branch, +you should add an appropriate note to the commit message.
-Update the MESA_MAJOR, MESA_MINOR and MESA_TINY version numbers in -configs/default. -Also update the VERSION line in the top-level Makefile. +Here are some examples of such a note:
+-
+
- NOTE: This is a candidate for the 9.0 branch. +
- NOTE: This is a candidate for the 8.0 and 9.0 branches. +
- NOTE: This is a candidate for the stable branches. +
Cherry-picking candidates for a stable branch
-Make sure the values in src/mesa/main/version.h are correct.
+Please use git cherry-pick -x <commit> for cherry-picking a commit
+from master to a stable branch.
Making a New Mesa Release
+-Update docs/news.html. +These are the instructions for making a new Mesa release.
+Get latest source files
-Check in all updates to git. +Use git to get the latest Mesa files from the git repository, from whatever +branch is relevant.
+ +Verify and update version info in VERSION
+
-Tag the files with the release name (in the form mesa_X_Y)
-with: git tag -a mesa_X_Y
-Then: git push origin mesa_X_Y
+Create a docs/relnotes/x.y.z.html file.
+The bin/bugzilla_mesa.sh and bin/shortlog_mesa.sh scripts can be used to
+create the HTML-formatted lists of bugfixes and changes to include in the file.
+Link the new docs/relnotes/x.y.z.html file into the main relnotes.html file.
+Update docs/index.html. +
-Make the tarballs
-Make a symbolic link from $(DIRECTORY) to 'Mesa'. For example,
-ln -s Mesa Mesa-7.5
-This is needed in order to make a correct tar file in the next step.
+Tag the files with the release name (in the form mesa-x.y)
+with: git tag -s mesa-x.y -m "Mesa x.y Release"
+Then: git push origin mesa-x.y
Make the tarballs
Make the distribution files. From inside the Mesa directory:
+ ./autogen.sh make tarballs
After the tarballs are created, the md5 checksums for the files will be computed. -Add them to the docs/relnotes-X.Y.html file. +Add them to the docs/relnotes/x.y.html file.
@@ -183,17 +255,20 @@ Copy the distribution files to a temporary directory, unpack them, compile everything, and run some demos to be sure everything works.
-Update the website and announce the release
+Update the website and announce the release
-Follow the directions on SourceForge for creating a new "release" and
-uploading the tarballs.
+Make a new directory for the release on annarchy.freedesktop.org with:
+
+
+mkdir /srv/ftp.freedesktop.org/pub/mesa/x.y
+
Basically, to upload the tarball files with:
-rsync -avP ssh Mesa*-X.Y.* USERNAME@frs.sourceforge.net:uploads/
+rsync -avP -e ssh MesaLib-x.y.* USERNAME@annarchy.freedesktop.org:/srv/ftp.freedesktop.org/pub/mesa/x.y/
Make an announcement on the mailing lists: -mesa-dev@lists.freedesktop.org, -mesa-users@lists.freedesktop.org +mesa-dev@lists.freedesktop.org, +mesa-users@lists.freedesktop.org and -mesa-announce@lists.freedesktop.org +mesa-announce@lists.freedesktop.org
- - +