On Wed, Sep 21, 2011 at 10:55 AM, Gregory Casamento < [email protected]> wrote:
> Riccardo, > > Just my $0.02 for what it's worth.... > > Strictly speaking there's nothing which would prevent you from doing > this with doxygen. It seems that the output for Objective-C using > Doxygen isn't so bad, if you look here: > > > http://www.duckrowing.com/wp-content/uploads/2010/03/Docs/html/interface_miscellaneous.html > > From this blog: > > > http://www.duckrowing.com/2010/03/18/documenting-objective-c-with-doxygen-part-i/ > > Pros and cons of using doxygen project wide: > > Pros... > Doxygen... > 1) appears to have more attractive output than autogsdoc in some respects > 2) is not maintained by us so we don't need to worry about maintenance. > I would add a 3: More developers use it over autogsdoc. People are more likely to know doxygen's syntax than autogsdoc's. > > Cons... > 1) Switching to doxygen would require us to change all of our existing > documentation to use doxygen's format instead of our own. IIRC they > are quite similar, but nevertheless this is an effort > And the reason I brought this up is because I'm starting to document corebase. Seeing as I'm starting from scratch I'm having a serious look at which doc generator to use. It would probably be a quite large effort move all of current gnustep documentation to doxygen and probably something that wouldn't happen overnight, as you suggest. > 2) Doxygen is not something that we control. We would have to go > through committee in order to change anything about it. So, > effectively our documentation's look and feel would be at the mercy of > someone else. > This is not entirely true, the output can be extensively modified (see * http://www.stack.nl/~dimitri/doxygen/customize.html*). Granted, that's a whole lot more work than just simply using autogsdoc, but it's also just a 1 time effort. Most projects simply use the default, though. Personally, I think the only major issue is actually moving the documentation. It's easy enough to do on new documentation but a major undertaking for the code we already have documented. In my opinion, even though the pro of us not maintaining it is > attractive, the #2 Con is unacceptable. I would say that, unless > there is a compelling reason to switch in the future, that we should > keep doing what we're doing. > > GC > -- > Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep >
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
