I tried to use the \xrefitem command as shown in the doxygen documentation
My Test.h file:
/** #page my_errors My Errors
* #brief Errors page
*
* Errors page contents.
*/
/** #error ERROR 101: in case a file can not be opened.
Check about file system read/write access.*/
#define MY_ERR_CANNOT_OPEN_FILE 101
/** \error ERROR 102: in case a file can not be closed.
Check about file system read/write access. */
#define MY_ERR_CANNOT_CLOSE_FILE 102
and used the ALIAS:
ALIASES += "error=\xrefitem my_errors \"\" \"\""
The Page My Errors gets created, but the documentation of the two errors does not show up in the output. Do I have to add some settings?
All other preferences are default. Doxygen version is 1.8.16
When using the comment /// \file at the top of the page the "errors" are displayed.
Though I get a warning:
my_errors:1: warning: multiple use of page label 'my_errors', (other occurrence: .../aa.h, line: 4)
which is not nice but doesn't disrupt the output.
Edit: I've just pushed a proposed patch regarding the warning, to github (https://github.com/doxygen/doxygen/pull/7260)
Related
I have a fair understanding of both how to document code and how to write "generic documentation" using #mainpage, #page, #subpage and related tags.
I would need to include requirements/specification documentation for the code.
My problem is to keep this kind of documentation (conceptually distinct from code documentation) close to code implementing functionality (i.e.: at least in the same file, sometimes even near specific classes/functions/methods) but still be able to collect it in an orderly fashion and present it in the #mainpage, outside file/class hierarchy.
What I would ideally need is to be able to place specific #page, #section, #subsection etc. randomly in the various source files and then be able to #include them in a specific order into #mainpage or some other #subpage.
Even better would be to be able to include the same snippet in both class/function full doc (not #brief, of course) and in the "front matter" linked in #mainpage.
Global effect I need to have is to have a "specification document" where I detail what the various parts of the code need to implement and then the "normal class/function/whatever" documentation doxygen id very good at providing.
The catch (i.e.: what I don't know how to do) is I would like to keep "specification" and implementation together in the source, but separate them in documentation, i.e.:
General Description: easy, this goes into #mainpage
Requirements: most likely at top of source file implementing them, how do I link/include in main page?
Specification: either right after Requirements at top of file or somewhere near class/function implementing it; also here I don't know how to link/include in "front matter" AKA: #mainpage.
Normal code documentation: here only thing I don't know is how include in class/function description the same "doc snippet" already used for (2) and (3).
Is this possible?
If so, what's the best practice?
Note: I could get the effect using a separate file for each "doc snippet" and then #includeing it in the right places, but that would defeat the whole purpose that's keep Requirements/Specification/code together while separating them in different sections in the resulting documentation.
Update: following #albert comment I tried the following:
in a standard Doxygen comment I added markers:
/**
* Initialization function.
*
* [AM_init]
* It needs to do a long series of tests to ensure AM can actually work.
*
* It should also allocate all dynamic memory needed to avoid runtime failures.
*
...
* It will be responsibility of system-level daemon to take appropriate action.
* [AM_init]
*
*
* #param ip_addr
* #param port
* #return
*/
static uint32_t AM_init(const char* ip_addr, uint16_t port) {
...
in the "front matter" definition I have (among other things):
/**
#page __init Initialization
#snippet{doc} CommandHandler.c AM_init
*/
The function documentation is rendered correctly (i.e.: the markers are removed)
OTOH the initialization page is "somewhat incomplete":
Initialization
It needs to do a long series of tests to ensure AM can actually work.
that's it.
Apparently the tag is found, but only the first line is actually included.
Further Update: Following #albert answer (accepted) I had success, but the following caveats:
Included snippet ([AM_init]) must be in a standard comment, not a doxygen one, otherwise snippet ends up included twice.
Included snippet must not have leading * (very common in "standard comments".
Included comments should have HTML controls (e.g.: <br/> for line termination) because Markdown constructs ("double newline", in the above case) are notrecognized.
In retrospect I think "Note" in Doxygen \snippet['{'option'}'] <file-name> ( block_id ) documentation addresses, more or less all the above, but I find it very cryptic and I would never have understood the implications without my nose being rubbed into them.
The last one is very annoying because I use a lot Lists and Tables and while HTML syntax is much more powerful, it is also much more difficult to write and to read in sources.
Finding a way to lift this limitation would be "very nice".
With the following code and the current doxygen version (1.9.4 (5d15657a55555e6181a7830a5c723af75e7577e2)) but also with the 1.9.1 (ef9b20ac7f8a8621fcfc299f8bd0b80422390f4b) version, I get good result:
bb.h
/// \file
/**
#page __init Initialization
#snippet{doc} CommandHandler.c AM_init
*/
CommandHandler.c
/// \file
/**
* Initialization function.
*/
/* [AM_init]
It needs to do a long series of tests to ensure AM can actually work.<br>
It should also allocate all dynamic memory needed to avoid runtime failures.<br>
It will be responsibility of system-level daemon to take appropriate action.<br>
[AM_init]
*/
/**
* \snippet{doc} this AM_init
*
* #param ip_addr
* #param port
* #return
*/
static uint32_t AM_init(const char* ip_addr, uint16_t port){}
Doxyfile
EXTRACT_STATIC = YES
EXAMPLE_PATH = .
QUIET = YES
Note: OP rightfully mentioned in further update that there are some things to take care of:
Included snippet ([AM_init]) must be in a standard comment, not a doxygen one, otherwise snippet ends up included twice.
Included snippet must not have leading * (very common in "standard comments".
Included comments should have HTML controls (e.g.: for line termination) because Markdown constructs ("double newline", in the above case) are not recognized.
When you run doxygen, you often get a lot of:
warning: some-thing-or-another is not documented.
For some items, you just want to fill in the documentation; but other are too trivial to document, or I just want listing without documentation.
Now, you could suppress these warnings with ///#cond and ///#endcond, but then the some-thing-or-another will be yanked out of the documentation, which is not what I wanted.
So, how can I make doxygen not warn me about certain items, while keeping the item in the documentaiton with no additional explanatory text?
A bit diving into the trick box.
Doxygen does have a command \noop but this is filtered out so it is not seen as documentation.
There are a number of non printing characters like and so defining something like:
/// \file
/** the documented fie
*/
void fie(void);
void fie1(void);
/** */
void fie2(void);
Will result in a warning for fie1 but not for fie and fie2.
The disadvantage is that doxygen thinks that fie2 is documented and thus creates a detailed section for it.
To overcome the "detailed section" problem one would like to have a command that says the function is documented but doesn't show anything and does not emit warnings about missing things, such a function is currently not present in doxygen.
I have this Interface property:
/**
* If enabled the log output will be printed locally in console.
* The log call line will not be overwritten unless {#link ILoggerConfig.useLoggerProcessors} is true
*/
printToConsole?: boolean;
In the generated docs it makes ILoggerConfig.useLoggerProcessors a clickable link but vscode intellisense doesn't :
The link part does not disturb me but vscode intellisense keeps the verbose {#link ILoggerConfig.useLoggerProcessors} part and when more than 2 other properties/classes/methods are referenced it is hard to read.
Can I make vscode parse the comments? I have searched for a tsdoc extension but have found none.
This is a bug as of VS Code 1.31. The following issues are tracking it:
https://github.com/Microsoft/TypeScript/issues/16498
https://github.com/Microsoft/TypeScript/issues/29617
Markdown links in JSDocs are already supported (but only to urls, not to symbols).
I am working on this project : https://sbl.inria.fr/doc, where the documentation is done with doxygen.
We were used to define the id of our sections with the symbol "-" to separate the words, for example :
\section sec-intro Introduction
However, it looks like the convention has changed since doxygen 1.8.15-git and only alpha-numerical characters are accepted, breaking almost all the pages in our documentation.
Unfortunately, we have a large number of pages, and before reviewing the whole documentation, I wanted to know if there is anything that I am missing, like a doxygen option to turn ON / OFF
[edit]
Here is a minimal example that does not work for me, with doxygen 1.8.15-git:
/**
\mainpage My Main Page
Abstract
\section home-intro Introduction
Intro
*/
//! Documented class test
class test{
};
I just create the configuration file and then run doxygen on the directory containing my .hpp file (so that there is no need to specify the path to my header) :
doxygen -g; doxygen
The main page on the output html contains "Abstract", but not the section, and there is a warning in the doxygen log :
test.hpp:6: warning: Invalid section id `home'; ignoring section
[edit 2]
It worked with doxygen 1.8.14. I cloned the project from the git repository, so I had the latest version. Using the tag version for the 1.8.14, it works fine. I changed the title.
I found the cause of the problem, it is a regression on:
Bug 740046 - Negative sign in -Foo::Bar ruins hyperlink in generated output
The github issue causing the problem is https://github.com/doxygen/doxygen/pull/5677 and the pull request https://github.com/doxygen/doxygen/pull/704.
The issue has been fixed in the proposed patch: https://github.com/doxygen/doxygen/pull/6388
In eclipse, when I want to document a function (in java or javascript source) I can just type /**, then hit enter, and I get a comment like this
/**
*
* Fluctuates all variables to more compatibly foo all the bars
*
* #PARAM {int} foo
*/
function flucvar (foo) {
}
When hitting enter inside the comment, eclipse automatically adds extra * at the beginning of each line.
Now I'm just getting into my textmate groove, and finding myself missing this little bit of functionality. Is there an equivilent bundle or command or something that would allow me to produce similar comments in textmate?
You need to create two snippets (I have them in the Source bundle).
First create a snippet for inserting JavaDoc comments. The snippet contains the following:
/**
* $0
*/
I have the snippet Activation set to Tab Trigger, using /** as the activation string. Every time I write /** and press Tab, I get a JavaDoc comment block. You can also use a keyboard shortcut if you like.
The second snippet is for continuing existing JavaDoc comments. The snippet contents are:
* $0
Note that there is an empty line before the * $0 line. Set Activation to Key Equivalent and the trigger key to return key. Set the Scope Selector string to comment.documentation.
Now if your language bundle supports the comment.documentation scope (like all of the included bundles seem to do), you should have working shortcuts for JavaDoc comments.
I took a look at TextMate's Java bundle, and I didn't see anything about inserting JavaDoc comments. However, it shouldn't be that hard to add such a feature to your Java bundle. It would likely be a Snippet, which you can read about in Chapter 7 of the TextMate manual (accessed from Help -> TextMate Help).
thanks for that answer. I just found this post on the macromates site
http://blog.macromates.com/2006/customization-screencast/
this appears to have a video/mailing list post that explains precisely how to do this.