To add a new GL extension to Mesa you have to do at least the following.
#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
gl_extensions
struct in mtypes.h
extensions.c
file.
Mesa's code style has changed over the years. Here's the latest.
Comment your code! It's extremely important that open-source code be well documented. Also, strive to write clean, easily understandable code.
3-space indentation
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:
if (condition) { foo; } 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
Local variable name example: localVarName (no underscores)
Constants and macros are ALL_UPPERCASE, with _ between words
Global variables are not allowed.
Function name examples:
glFooBar() - a public GL entry point (in glapi_dispatch.c) _mesa_FooBar() - the internal immediate mode function save_FooBar() - retained mode (display list) function in dlist.c foo_bar() - a static (private) function _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.
These are the instructions for making a new Mesa release.
Use git to get the latest Mesa files from the git repository, from whatever branch is relevant.
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.
Update the MESA_MAJOR, MESA_MINOR and MESA_TINY version numbers in configs/default. Also update the VERSION line in the top-level Makefile.
Make sure the values in src/mesa/main/version.h are correct.
Update docs/news.html.
Check in all updates to git.
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
Make the distribution files. From inside the Mesa directory:
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.
Copy the distribution files to a temporary directory, unpack them, compile everything, and run some demos to be sure everything works.
Follow the directions on SourceForge for creating a new "release" and uploading the tarballs.
Basically, to upload the tarball files with:
rsync -avP ssh Mesa*-X.Y.* USERNAME@frs.sourceforge.net:uploads/
Update the web site by copying the docs/ directory's files to
/home/users/b/br/brianp/mesa-www/htdocs/ with:
sftp USERNAME,mesa3d@web.sourceforge.net
Make an announcement on the mailing lists: mesa-dev@lists.freedesktop.org, mesa-users@lists.freedesktop.org and mesa-announce@lists.freedesktop.org