Combine docs of libraries with overlapping postfix - doxygen

I want to combine the docs of two libraries: Bar and MyBar. However, this is causing strange problems with overlapping paths.
Consider this project:
Doxyfile
Bar/config.h
MyBar/config.h
with Doxyfile
INPUT = Bar MyBar
and Bar/config.h:
/**
Lorem ipsum
\file Bar/config.h
*/
/**
Some bar lib.
*/
namespace Bar {
} // namespace Bar
and MyBar/config.h:
/**
Lorem ipsum
\file MyBar/config.h
*/
#include <Bar/config.h>
/**
Some other library
*/
namespace MyBar {
} // namespace MyBar
Building with doxygen 1.9.1 gives the following warning:
Bar/config.h:4: warning: the name 'Bar/config.h' supplied as the argument in the \file statement matches the following input files:
/myprojectdir/Bar/config.h
/myprojectdir/MyBar/config.h
Please use a more specific name by including a (larger) part of the path!
I really don't know how to solve this: there is no larger part of the path to be specified (in relative sense).

The usage of the directory name in the \file is a potential source of problems.
When the documentation block of the file is in the file itself there are 2 solutions:
use the \file command without the name of the file
use the \file command without the directory
Personally I would go for the first solution as in case of a renaming of the file this has not to be done with the \file command as well.

Related

another doxygen generating nothing

i use doxygen 1.8.15 for the first time.
I generate Doxyfile by doxygen -g and try to create documentation just by doxygen.
Among other i have in the base directory test.cpp looking like this:
/**
* This is a test. doc for an enum
*/
enum Test {
/**
* doc for an item
*/
SomeItem
};
I expect the html output in html/index.html but this is essentially an empty site.
The following is an extract of the output:
Parsing files
Preprocessing /home/ernst/Ankrit/Software/Products/Recon/recon/Mbed/main.cpp...
Parsing file /home/ernst/Ankrit/Software/Products/Recon/recon/Mbed/main.cpp...
Reading /home/ernst/Ankrit/Software/Products/Recon/recon/Mbed/mbed_settings.py...
Parsing file /home/ernst/Ankrit/Software/Products/Recon/recon/Mbed/mbed_settings.py...
Preprocessing /home/ernst/Ankrit/Software/Products/Recon/recon/Mbed/test.cpp...
Parsing file /home/ernst/Ankrit/Software/Products/Recon/recon/Mbed/test.cpp...
Building group list...
As you can see test.cpp is inside. But in the results nothing on cpp shows up, only mbed_settings.
What did i do wrong?
When e.g. cpp code doxygen has the "habit" of not finding some information when no corresponding .h file is present.
With the aid of the \file command this problem can be overcome, so the code:
/// \file
/**
* This is a test. doc for an enum
*/
enum Test {
/**
* doc for an item
*/
SomeItem
};
gives the requested result.

Dynamic hyper link reference in Doxygen

Can Doxygen build references such as a link is defined somewhere only once and any reference to it gets the corresponding redirection?
This would allow for \see commands pointing to the right resource without the need of duplicating the URL everywhere in the code, while making it easy to change said link if need be.
Generated docs would look a little bit like this:
mainpage.md
Useful links are defined here
A guide to something
Datasheet of something
source.c File Reference
(...)
See also
A guide to something //points to URL defined in mainfile.md
[EDIT]
Thanks to #albert in the comments, I've managed to do just that using \snippetdoc, however any text after the block-id makes doxygen unable to render the snippet.
Working example:
Knowing that my links are defined in the docs/mainpage.dox file like this:
[url_to_link1]
Link description
[url_to_link1]
[url_to_link2]
Link description
[url_to_link2]
This works:
/**
* \file
* \section links "Useful Links"
* - \snippetdoc docs/mainpage.dox url_to_link1
* - \snippetdoc docs/mainpage.dox url_to_link2
*/
This doesn't:
/**
* \file
* \brief Some function definition
* \see API reference on specific subject (more info: \snippetdoc docs/mainpage.dox url_to_link1)
*/
Doxygen version is 1.8.14
As indicated in the question and comments a solution for this problem lies in the command \snippetdoc, an alternative is to define an ALIAS (in Doxyfile the doxygen configuration file) for the reference and use the defined command / alias on the required places.
As indicated by OP possible solutions by means of \snippetdoc are:
/**
* \file
* \section links "Useful Links"
* - \snippetdoc docs/mainpage.dox url_to_link1
* - \snippetdoc docs/mainpage.dox url_to_link2
*/
The following version does not work as indicated by OP:
/**
* \file
* \brief Some function definition
* \see API reference on specific subject (more info: \snippetdoc docs/mainpage.dox url_to_link1)
*/
The problem is that the definition of \snippetdoc is \snippetdoc <file-name> ( block_id ) where (block_id) means that it reads till the end of the line (see the doxygen documentation) and thus the closing ) is part of the block_id and cannot be resolved.
A possible better implementation could be <block_id> so that block_id is a single word. Problem for this is that this that it might break existing documentation where e.g. spaces or dots are used in the block_id.
There are a number of solutions for this problem:
1) Define the closing ) as part of the block_id (in the not working version):
[url_to_link1)]
Link description)
[url_to_link1)]
2) Place the closing ) on the next line (definition can stay as in the question):
/**
* \file
* \brief Some function definition
* \see API reference on specific subject (more info: \snippetdoc docs/mainpage.dox url_to_link1
* )
*/
3) Define 2 definitions:
[url_to_link1)]
Link description)
[url_to_link1)]
[url_to_link1]
Link description
[url_to_link1]
I general solution 2) is the preferred solution as the solution. All text following the block_id has to be on the next line.

doxygen AUTOLINK_SUPPORT and sa

Using Doxygen version 1.8.4:
When AUTOLINK_SUPPORT = NO in the configuration file, the HTML See Also section references generated by \sa (or #see) are not active links to the referenced method. When AUTOLINK_SUPPORT = YES the \sa references are active links as expected.
This seems to be a relatively recent change to doxygen behaviour: I've been using AUTOLINK_SUPPORT = NO for years to avoid having to mark all the words in the description text that would otherwise result in undesired automatic links with a '%' character, and the See Also references had remained active links.
Is there a known workaround that enables \sa references to remain active links while still having global AUTOLINK_SUPPORT disabled?
Here is a trivial test file:
/** The Fooy class.
*/
class Fooy
{
public:
/** foo
The alternative is {#link bar(int, int)const the bar method}
#param value A value.
#return The value incremented.
#see bar(int, int)const
*/
int foo (const int value) const;
/** bar
The alternative is {#link foo(const int)const the foo method}
#param value A value.
#param number A number.
#return The value plus the number.
#see foo(const int)const
*/
int bar (int value, int number) const;
};
Using the auto-generated Doxyfile (doxygen -g) doxygen version 1.8.8 produces, without any warnings, the expected HTML results: The {#link bar(int, int)const the bar method} syntax results in a link named "the bar method" (and likewise for the other #link), and the #see references result in the expected links having the method signatures.
If the Doxyfile is changed so AUTOLINK_SUPPORT = NO doxygen now produces HTML in which the #see signatures are no longer links, but is otherwise the same.
If " the bar method" is removed from the first #link command doxygen outputs -
Fooy.hh:9: warning: unable to resolve link to `bar(int, int)' for \link command
And the resulting HTML has the single word "const" as the link to the html/classFooy.html file instead of the method signature and correct link. However, if the single space is removed after the comma in the argument list of the method signature the warning disappears and the link is now correct with the full signature text. Note that the space character
in the foo argument list of the second #link command must remain to have a correct signature, so removing the text " the foo method" from the command will always result in an incorrect parsing by doxygen. Restoring AUTOLINK_SUPPORT = YES does not change this behaviour. This suggests a flaw in the doxygen parser.
Back to the initial issue of getting the #see references to be links in the HTML output when AUTOLINK_SUPPORT = NO in the Doxyfile. Putting the method signatures in the #see commands inside {#link ...} wrappers fails as described above (only if the method signature has no space character does it work correctly). If the wrappers are replaced with the new #link ... #endlink syntax (and the new syntax used with the other {#link ...} commands) then the HTML output from doxygen is the expected results with full method signatures and correct links.
So the answer to this problem is that doxygen is not backwards compatible with previous in-code command syntax. Unless some workaround is known, all existing code files must be edited to accommodate the changes to the doxygen parser.
Sigh.

doxygen separate interface(.h)/implemetation(.c) documentation

I'm trying to generate a doxygen document where I have two documentation instances for functions. One describes the usage(interface) of the functions that get pulled from the function header in the .h file and the other describes implementation of the function that gets pulled from the .c file. I basically want to describe the same function in two different ways based on where the file that the description came from(.h or .c). I thought this would help the usability of the document since you can easily ignore the implementation details if you only care about how to use the functions. My best attempt was to try to add the .h and the .c files to separate groups like this.
example.h
/**
* #defgroup exampleInterface Example Interface
* #{
*/
/**
* This is the header file so I describe how to use this function
* #param arg
* #returns something
*/
int someFunction(int arg);
/**
* #}
*/
example .c
/**
* #defgroup exampleImpl Example Implementation
* #{
*/
/**
* This is the .c file so I describe how this function is implemented.
*/
int someFunction(int arg)
{
... Some code ...
}
/**
* #}
*/
The result was that the function header descriptions were still combined. Is there anyway to accomplish this in doxygen? Maybe there is another way I should look at this problem.
Thanks.
A possible hack you could try is to use the #internal command for the implementation which would mean you would run doxygen twice: once without the internal (for the external definitions) and the other with the inernal which would combine them.

JSDoc - mark some code to not be parsed but retain documentation?

I'm trying to document a Javascript file with JSDoc(3) like so:
/** 1 if gnome-bluetooth is available, 0 otherwise
* #type {boolean}
* #const
*/
const HAVE_BLUETOOTH = #HAVE_BLUETOOTH#;
Now the file (called config.js.in) is not on its own valid Javascript; the file gets run through a Makefile which substitutes an appropriate value for #HAVE_BLUETOOTH#.
When I try to run JSdoc on this, it (understandably) balks because of the syntax error in the file.
Is there some way to tell JSDoc to ignore all code in this file but simply take into account the annotations? (I might have to add #name tags to each doclet to completely separate the documentation from the code; that's fine).
Something like:
/** 1 if gnome-bluetooth is available, 0 otherwise
* #name HAVE_BLUETOOTH
* #type {boolean}
* #const
*/
/** #ignore */ // somehow ignore from here onwards
const HAVE_BLUETOOTH = #HAVE_BLUETOOTH#;
/** !#ignore */ // somehow don't ignore from here onwards (although I'd be happy
// to ignore the entire file)
I'd prefer not to modify the code part of the file, if possible (I'm adding documentation to an existing project). For example, I could probably get around it with
const HAVE_BLUETOOTH = parseInt('#HAVE_BLUETOOTH#', 10);
which would make the file have valid JS syntax again so that the parser doesn't complain, but this also means I'm modifying the code of the original file which I want to avoid (I prefer to just add documentation).
cheers
My case is similar because I use JSDoc to comment my .less and .css file. When I running JSDoc on set of file, I have the same issue.
So, I resolve my problem (with JSDoc 3.3.3) with the commentsOnly JSDoc plugin
https://github.com/jsdoc3/jsdoc/blob/master/plugins/commentsOnly.js
I have create this config.json:
{
"source": {
"includePattern": ".+\\.(css|less)?$"
},
"plugins": [
"plugin/commentsOnly"
]
}
with the commentsOnly.js file into a plugin/ directory (consider plugin/ and config.json are in same folder) and in this folder I execute the following CLI command:
jsdoc -c ./config.json ./assets/stylesheets/common.less
And it's work ! There are no reason this do not work with your files.
Hope I help you ;)