Using doxygen (or something similar) to generate API docs [was [PATCH 4/4] Add a function string_list_longest_prefix()]
I'm renaming this thread so that the bikeshedding can get over ASAP. On 09/10/2012 07:48 PM, Andreas Ericsson wrote: On 09/10/2012 06:33 PM, Jeff King wrote: On Mon, Sep 10, 2012 at 09:24:17AM -0700, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: Also, better documentation in header files could enable the automatic generation of API docs (e.g., via doxygen). Yeah, perhaps you may want to look into doing an automated generation of Documentation/technical/api-*.txt files out of the headers. I was just documenting something in technical/api-* the other day, and had the same feeling. I'd be very happy if we moved to some kind of literate-programming system. I have no idea which ones are good or bad, though. I have used doxygen, but all I remember is it being painfully baroque. I'd much rather have something simple and lightweight, with an easy markup format. For example, this: http://tomdoc.org/ Looks much nicer to me than most doxygen I've seen. But again, it's been a while, so maybe doxygen is nicer than I remember. I don't have a personal preference for what system is used. I mentioned doxygen only because it seems to be a well-known example. From a glance at the URL you mentioned, it looks like TomDoc is only applicable to Ruby code. Doxygen has a the very nifty feature of being able to generate callgraphs though. We use it extensively at $dayjob, so if you need a hand building something sensible out of git's headers, I'd be happy to help. My plate is full. If you are able to work on this, it would be awesome. As far as I'm concerned, you are the new literate documentation czar :-) Most importantly, having a convenient system of converting header comments into documentation would hopefully motivate other people to add better header comments in the first place, and motivate reviewers to insist on them. It's shocking (to me) how few functions are documented, and how often I have to read masses of C code to figure out what a function is for, its pre- and post-conditions, its memory policy, etc. Often I find myself having to read functions three layers down the call tree to figure out the behavior of the top-layer function. I try to document things as I go, but it's only a drop in the bucket. libgit2 uses doxygen btw, and has done since the start. If we ever merge the two, it would be neat to use the same. That would be a nice bonus. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using doxygen (or something similar) to generate API docs [was [PATCH 4/4] Add a function string_list_longest_prefix()]
On Mon, Sep 10, 2012 at 09:21:12PM +0200, Michael Haggerty wrote: I'm renaming this thread so that the bikeshedding can get over ASAP. Thanks. :) http://tomdoc.org/ Looks much nicer to me than most doxygen I've seen. But again, it's been a while, so maybe doxygen is nicer than I remember. I don't have a personal preference for what system is used. I mentioned doxygen only because it seems to be a well-known example. From a glance at the URL you mentioned, it looks like TomDoc is only applicable to Ruby code. Yeah, sorry, I should have been more clear; tomdoc is not an option because it doesn't do C. But what I like about it is the more natural markup syntax. I was wondering if there were other similar solutions. Looks like NaturalDocs is one: http://www.naturaldocs.org/documenting.html On the other hand, doxygen is well-known among open source folks, which counts for something. And from what I've read, recent versions support Markdown, but I'm not sure of the details. So maybe it is a lot better than I remember. Doxygen has a the very nifty feature of being able to generate callgraphs though. We use it extensively at $dayjob, so if you need a hand building something sensible out of git's headers, I'd be happy to help. It has been over a decade since I seriously used doxygen for anything, and then it was a medium-sized project. So take my opinion with a grain of salt. But I remember the callgraph feature being one of those things that _sounded_ really cool, but in practice was not all that useful. My plate is full. If you are able to work on this, it would be awesome. As far as I'm concerned, you are the new literate documentation czar :-) Lucky me? :) I think I'll leave it for the moment, and next time I start to add some api-level documentation I'll take a look at doxygen-ating them and see how I like it. And I'd invite anyone else to do the same (in doxygen, or whatever system you like -- the best way to evaluate a tool like this is to see how your real work would look). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using doxygen (or something similar) to generate API docs [was [PATCH 4/4] Add a function string_list_longest_prefix()]
On 09/10/2012 11:56 PM, Jeff King wrote: On Mon, Sep 10, 2012 at 09:21:12PM +0200, Michael Haggerty wrote: My plate is full. If you are able to work on this, it would be awesome. As far as I'm concerned, you are the new literate documentation czar :-) Lucky me? :) I was nominating Andreas, who rashly volunteered to help. But don't feel left out; there's enough work to go around :-) I think I'll leave it for the moment, and next time I start to add some api-level documentation I'll take a look at doxygen-ating them and see how I like it. And I'd invite anyone else to do the same (in doxygen, or whatever system you like -- the best way to evaluate a tool like this is to see how your real work would look). I agree with that. A very good start would be to mark up a single API and build the docs (by hand if need be) using a proposed tool. This will let people get a feel for (1) what the markup has to look like and (2) what they get out of it. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using doxygen (or something similar) to generate API docs [was [PATCH 4/4] Add a function string_list_longest_prefix()]
On 09/10/2012 11:56 PM, Jeff King wrote: On Mon, Sep 10, 2012 at 09:21:12PM +0200, Michael Haggerty wrote: I'm renaming this thread so that the bikeshedding can get over ASAP. Thanks. :) http://tomdoc.org/ Looks much nicer to me than most doxygen I've seen. But again, it's been a while, so maybe doxygen is nicer than I remember. I don't have a personal preference for what system is used. I mentioned doxygen only because it seems to be a well-known example. From a glance at the URL you mentioned, it looks like TomDoc is only applicable to Ruby code. Yeah, sorry, I should have been more clear; tomdoc is not an option because it doesn't do C. But what I like about it is the more natural markup syntax. I was wondering if there were other similar solutions. Looks like NaturalDocs is one: http://www.naturaldocs.org/documenting.html On the other hand, doxygen is well-known among open source folks, which counts for something. And from what I've read, recent versions support Markdown, but I'm not sure of the details. So maybe it is a lot better than I remember. Markdown is supported, yes. There aren't really any details to it. I don't particularly like markdown, but my colleagues tend to use it for howto's and whatnot and it can be mixed with other doxygen styles without problem. Doxygen has a the very nifty feature of being able to generate callgraphs though. We use it extensively at $dayjob, so if you need a hand building something sensible out of git's headers, I'd be happy to help. It has been over a decade since I seriously used doxygen for anything, and then it was a medium-sized project. So take my opinion with a grain of salt. But I remember the callgraph feature being one of those things that _sounded_ really cool, but in practice was not all that useful. It's like all tools; Once you're used to it, it's immensely useful. I tend to prefer using it to find either code in dire need of refactoring (where the graph is too large), or engines and exit points. For those purposes, it's pretty hard to beat a good callgraph. My plate is full. If you are able to work on this, it would be awesome. As far as I'm concerned, you are the new literate documentation czar :-) Lucky me? :) I think he was talking to me, but since you seem to have volunteered... ;) I think I'll leave it for the moment, and next time I start to add some api-level documentation I'll take a look at doxygen-ating them and see how I like it. And I'd invite anyone else to do the same (in doxygen, or whatever system you like -- the best way to evaluate a tool like this is to see how your real work would look). That's one of the problems. People follow what's already there, and there are no comments there now so there won't be any added in the future :-/ -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
