<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang="FI" link="blue" vlink="purple"> <div class="WordSection1"> <div> <div> <div> <div> Hi all,<o:p></o:p> <o:p> </o:p> </div> <div> >I'm not aware of any public web servers that serve up the doxygen documentation right now. If you can find one (or set up one, or convince the <a href="http://freedesktop.org">freedesktop.org</a> >maintainers to set up one), I would be in favor of putting overview style documentation in doxygen format. Otherwise I think it would be better to add overview style >documentation to the existing docs/ directory in html form, because that's what people see if they go to <a href="http://www.mesa3d.org/">http://www.mesa3d.org/</a>.<o:p></o:p> </div> <div> <o:p> </o:p> There is a link to the doxygen magicks, over at “Developer Topics -> Source Code” and then a link as the last word in the text “ .. documentation here”. The link is dead; however, the link to bufferobj.c works. <o:p></o:p> <o:p> </o:p> I really think the docs should be “part of the source code” to help guarantee they do not rot; who would I contact of <a href="http://www.mesa3d.org">http://www.mesa3d.org</a> so that the link to the source code would work? It will mean that whoever maintains the site will need to run #cd doxygen && make, which I hope would not be a big deal.<o:p></o:p> <o:p> </o:p> </div> <div> >If we can find or set up a public server serving up the latest doxygen documentation (and that's a big "if"), then I'd be in favor of adding group tags so that module >categorization is in the sources. But I don't understand the benefit of having two separate doxygen outputs (one for headers and one for all code). The fact is, the only >consumers of the doxygen output are going to be mesa developers and people who are interested in understanding the source code. That argues for one piece of >doxygen output that contains all the code. Besides, we currently have zero public doxygen builds of Mesa; I'd far prefer to take the incremental step of changing this >to one, and seeing how it goes for a while, rather than jumping to two and risking confusing people.<o:p></o:p> </div> <div> <o:p></o:p> I agree with you, two doxygen runs is silly since Mesa is an implementation of documented and speced API; thus the only doxygen documentation would include sources that are linked so that a developer can quickly navigate. As for the how, this is what I am thinking of doing:<o:p></o:p> <![if !supportLists]>1. <![endif]>First just tweak the .doxy files found in doxygen (they have that various directories are processed by doxygen separately so that the module thing is kind of done by directory already). However, write the overview text (new files) in each of the main directories. The text would be in a \mainpage header. Since each directory is a separate run, it will then present the overview text of that directory when clicked. If a directory already has a main page then just edit that.<o:p></o:p> <![if !supportLists]>2. <![endif]>Once the documents look good and people are happy with AND there is update from the websites to make and host the doxygen stuff, then redo the doxygen files a bit to one doxygen file and then add group tags to the headers. <o:p></o:p> <o:p> </o:p> The 2nd step is not really needed if people are happy with the results of (1)… and skipping (2) has one positive side-effect, one can then, if one chooses, organize the sources into sub-groups of a main directory. Given that step 1 is not even started, I think figure out 2 if 1 gets done as needed.<o:p></o:p> <o:p> </o:p> </div> <div> >There's a lot of code in core Mesa that is shared by all drivers. Even if your documentation efforts only wind up affecting i965 code and shared code, they will still >benefit everyone. I think the best way to address this is to take the "patches welcome" attitude--if you set up a public doxygen server, and get the documentation into >good enough shape that it is useful, either the gallium folks will want to contribute (in which case they can, by updating comments in the gallium code), or they won't >(in which case they still will benefit from the doxygen documentation in core Mesa). Either way it's a win.<o:p></o:p> <o:p> </o:p> I’ll try to get something set up; but to make progress faster and now, I’ll start reading and then writing those \mainpage texts for each main directory. I’ll start posting the text here once I’ve written something that has some info it. Along those lines, which is preferred by those doing the reading and checking posting the text as a patch or just the text itself?<o:p></o:p> <o:p> </o:p> Best Regards<o:p></o:p> -Kevin <o:p></o:p> <o:p> </o:p> </div> </div> </div> </div> </div> </body> </html>