Depends on previous patches as I'm not sure how to just create a single patch for that one file with Git.
________________________________ From: devel devel-bounces@libdivecomputer.org on behalf of Jef Driesen jef@libdivecomputer.org Sent: 08 November 2016 20:01 To: Anton Lundin Cc: devel@libdivecomputer.org Subject: Re: Patches to add doxygen support to build and add some comments.
On 08-11-16 20:48, Anton Lundin wrote:
On 08 November, 2016 - Jef Driesen wrote:
On 07-11-16 13:05, Anton Lundin wrote:
On 04 November, 2016 - Ryan McLean wrote:
|You also started to document some internal stuff. But none of that is |supposed to end up in the documentation! The part that needs to be |documented are the public header files.
I started there as I was trying to understand how libdivecomputer acutally works and figured all should be documented. I thought there would be two types of developers:
- those using your public API such as subsurface
- those wanting to contribute to libdivecomputer itself.
Maybe should have two subfolders in the docs dir; public API and fulldoc.
One can use the http://www.stack.nl/~dimitri/doxygen/manual/commands.html#cmdinternal to separate whats "internal" and whats external documentation.
That way one can "hide" internal api's when generating the "normal" documentation, but still have them documented the same way, and include them when generating the "internal" documentation for libdivecomputer.
It's even more simple: only the header files in the include directory are public, everything else is private.
So you're saying there are no cases what so ever for documenting the internal functions of libdivecomputer?
Of course not. I'm just saying that the distinction between public and private can be based on the directory.
Jef _______________________________________________ devel mailing list devel@libdivecomputer.org http://libdivecomputer.org/cgi-bin/mailman/listinfo/devel