How do i group all the functions, classes, defines etc of a file?
Example file:
/*!
* \file
* \ingroup myGroup
*/
/*!
* this is my function.
*/
int myfunc();
Now, if look at the output, only the file is added to that group. The function is not. i need to add \ingroup myGroup to that file to add it. Can that be done by brackets{} or any way else?
Thans to alberts persistence i found a working way:
/*!
* \file
* this is my testfile
* \ingroup UnitName
* \addtogroup UnitName
* \{
*/
/*!
* this is my function.
*/
int myfunc();
/*! \} */
This generates the wanted output. The File andthe function is added correctly.
It does not work with \ingroup. It puts the function into the files section (i upgraded to the latest version of doxygen with the same outcome.
Related
I have some code like the following example:
/** #file HelloPi.c */
/** The definition of pi */
#define PI 3.1415
/** #brief The main function.
* #details Prints the value of #PI, which is actual defined as 3.1415. */
void main()
{
printf("The value of pi is %f\n",PI);
}
In my doxygen dokumentation I would like to to have NO macro expansion for PI (and other defines) in general.
But on one paragraph in the documentation I need the value of pi (e.g. #details description of the main function).
Is there any possibility to expand the macro at this single part of documentation with a command or something? Something like /** #details ...the value of #PI is $(PI).*/
I only know the build-in MACRO_EXPANSION tag which works for the whole documentation: https://www.doxygen.nl/manual/preprocessing.html :-/
Thanks for help :)
Jan
Edit:
Add an other example which maybe better describes my Problem:
/** #file ErrorHandling.c */
#define ERR_CODE_POWERUNIT 1001 ///< Error in power unit */
/** #page errors
* [value of ERR_CODE_POWERUNIT ] means \copybrief ERR_CODE_POWERUNIT */
void errHandler(int error)
{
if(error=ERR_CODE_POWERUNIT)
printf("Error %d occur\n",ERR_CODE_POWERUNIT);
}
In the documentation I would like to have:
"1001 means Error in power unit"
In doxygen there is no possibility to do a conversion of a predefined variable (only) in the documentation.
You used in your documentation the an environment variable $(PI) but ths is quite cumbersome as you have to st the environment variable each time.
A better solution would be to use an ALIASES like:
ALIASES += pi=3.1415
or
ALIASES +\= "The value of PI = 3.14159265359..."
with which you define a command \pi that can be used in the documentation and will be replaced with the text / commands in the alias.
/** #details ...the value of #PI is \pi.*/
would result in something like (by head:
...the value of #PI is 3.1415
I'm writing the documentation of a C project using Doxygen.
In the documentation of a function, one can refer to an argument of the function using \p. I want to use the " 's " possessive idiom in my text, e.g. writing the object's name. Here is a code sample that triggers the issue:
/**
* #file
* #brief Main C entry point
* #author Vincent Siles
*/
#include <stdio.h>
typedef struct {
int foo;
int bar;
} foobar;
/**
* #brief blabla
*
* toto \p in's field foo.
* toto \p in 's field foo.
*
* #param in input
*/
void test(foobar *in)
{
printf("%d %d\n", in->foo, in->bar);
}
int main(void)
{
foobar xxx = { .foo = 0, .bar = 0};
test(&xxx);
return 0;
}
The generated HTML features:
<p>blabla </p>
<p>toto <code>in's</code> field foo. toto <code>in</code> 's field foo.</p>
As you can see, both <code> parts are unsatisfactory: the first one has the " 's " inside it and it feels wrong, and the second one has an additional space.
In this case, I could rephrase into the field of \p in, but that's not always possible. Is there a way to output <code>in</code>'s field ?
For the record, I'm using version 1.8.11, and I have this issue with the default configuration, created by doxywizard + optimize for C/PHP. The full configuration can be found here.
It is not possible with the \p command.
However, as a workaround you can use `in`'s instead of \p in's.
But note that it might look a bit weird since the <code>in</code> part will use a different font as the 's which therefore might appear bigger or smaller:
Can I define all custom types in a separate file (e.g. types.jsdoc), so that they can be reused throughout the application? What's the right way to do it?
/**
* 2d coordinates.
* #typedef {Object} Coordinates
* #property {Number} x - Coordinate x.
* #property {Number} y - Coordinate y.
*/
You can define types in a module (eg. typedefs.js). The module contains your JSDoc typdefs and can simply export an unused property.
// typedefs.js
/**
* #typdef foo
* #property {string} bar
*/
// etc.
exports.unused = {};
To use it, import the module where you need to reference these typdefs:
const typedefs = require("./typedefs");
/** #type {typedefs.foo} */
const fb = { bar: "hello" };
You may wish to annotate typedefs.js as a #module or #namespace. Because I'm using "tsd-jsdoc" to generate a types.d.ts file, and due to the way TypeScript now interprets modules vs. namespaces, I've annotated my typedefs.js file as a #namespace and documented each typedef as a member of that namespace:
/**
* #namespace typedefs
*/
/**
* #typedef foo
* #property {string} bar
* #memberof typdefs
*/
Hope that helps.
This is a TypeScript-flavored JSDoc specific answer, but I'm having success using a triple-slash directive to "import" all the types from another file. This has the advantage of not actually adding an unused import which can upset linters and bundlers.
I'm putting my shared types in one file called typedefs.js like this:
// typedefs.js
/**
* #typedef {Object} Foo
* #property {string} bar
*/
/**
* #typedef {Object} Baz
* #property {number} buzz
*/
and then using /// <reference path="typedefs.js" /> in the other files to access the shared types like this:
// randomThing.js
/// <reference path="typedefs.js" />
/**
* Turn a Foo into a Baz
*
* #param {Foo} a
* #return {Baz}
export function (a) {
return { buzz: a.bar.length };
}
The tricky thing though is that now typedefs.js is just being referenced in a comment, bundlers like rollup miss it completely. So I'm combining it with my old consts.js that exports a few constants and is imported in at least one place. That way the typedefs are still included in the rollup output.
I hope someone else finds this helpful.
p.s. rollup will completely exclude a pure JSDoc typedefs.js file _even if you have import './typedefs.js' because of tree-shaking! Gotta run rollup with --no-treeshake to keep those comments in the rollup output.
In vscode, the import('./path/to/types.js').def tag works perfectly fine.
For e.g.
types.js
/**
* #typedef {Object} connection
* #property {String} id
* #property {Number} pingRetries
* #property {(data:Object) => void} sendJSON
*/
exports.unused = {};
And someFile.js
/**
* #param {import('./types').connection} param
*/
const someFunc = (param) => {}
Also, note that the exports.unused = {} is necessary in the types.js file, otherwise the auto-import of import('./types') would not work and you may have to type it by yourself.
I just tried with VSCode and it works only if the separate file is opened in the editor. If not, external typedefs are typed as any
I usually do something similar in my projects, the difference being I use the extension .js to name the file. Webstorm works perfectly and is able to check types and auto-complete just fine. It won't recognize the .jsdoc extension (I just checked), so stick to .js even if the file doesn't contain any code statement.
I've had success with simply creating my types in a typedefs.js file and referencing using the ts/vscode import(path/to/file).Foo tag. JSDoc does not support this syntax out of the box, so I suggest also using jsdoc-tsimport-plugin in order to parse your docs.
Eg: typedef.js:
/**
* #typedef {Object} Foo
* #property {string} id
*/
/**
* #typedef {Object} Bar
* #property {string[]} things
*/
// having to export an empty object here is annoying,
// but required for vscode to pass on your types.
export {};
coolFunction.js
/**
* This function is super dope
* #param {import('../typedef').Foo[]} foo - a foo
* #return {import('../typedef').Bar[]} bar - an array of bars
*/
export function (foo) {
// do cool things
return bar;
}
I'm also using tsd-jsdoc to create a types.d.ts file, and this implementation is successfully creating the types. I had trouble with declaring modules and namespaces with the types file— just creating standalone typedefs for said models worked best for me.
All,
I am trying to get a handle on doxygen tags, and have encountered the following 'issue'.
In the code shown below, if I remove the #file doxytest.c from the second line, all is well. If, however, I leave it in, the output log contains this:
/Users/bp/learn/gendoxy/gendoxy/doxytest.c:10: warning: argument 'int' of command #param is not found in the argument list of foobar0(int folder)
/Users/bp/learn/gendoxy/gendoxy/doxytest.c:10: warning: The following parameters of foobar0(int folder) are not documented:
parameter 'folder'
This makes no sense to me (should it?) This is in a '.c' file, running on a MacOS.
What am I doing wrong? -- I would like to have the #file tag, and no warnings/errors from doxygen.
Or, gasp!, is this a bug?
/*!
* #file doxytest.c
*
* #author bp
* #version 0.0.1
* #copyright (2013) we be nerds,LLC
*/
/*!
* #brief void foobar0 ( int folder )
* does little to better the world.
*
* #param [in] int folder :- one small step
*
*/
void foobar0 ( int folder )
{
for (int ii = 0; ii < folder; ii++)
{
foobar1( ii );
}
}
/*!
* #brief foobar2 ( int x )
* does half of what foobar1 does.
*
*/
void foobar1( int x )
{
return( x /2 );
}
Do not include the variable type in the doxygen comment
* #param [in] folder :- one small step
Otherwise it thinks your documenting the variable 'int', and it also thinks you forgot to document the variable 'folder'.
So yes, you should keep the #file tag. Honestly I find it strange that removing the #file tag made the warning go away.
If I use "after the member" documentation for function parameters, for example, use //!< after each parameter, instead of #param in the header, the "Parameters" section is always placed after "Return" in the generated output file.
Is is possible to define the order so that "Parameters" will be placed before "Return"?
/**
*****************************************************************************************
* #brief Test API
*
* #usage This API can be called at any time
*
* #return 0 if successful; or 1 if failed
****************************************************************************************/
int TestAPI(
int argument1, //!< first argument
int argument2 //!< second argument
);
I've just tried out your code with Doxygen 1.7.5.1, and confirmed that with your code, the Parameter list in the output comes after the description of Return.
This is a shame, as the //!< style is much nicer than having to re-state the names of all the parameters with #param:
/**
*****************************************************************************************
* #brief Test API
*
* #usage This API can be called at any time
*
* #param argument1 first argument
* #param argument2 second argument
*
* #return 0 if successful; or 1 if failed
****************************************************************************************/
int TestAPI2(
int argument1,
int argument2
);
I had a look in the Doxygen Bugzilla bug database, to see if it was a relatively recent bug (as then you could try reverting to an older installation).
I believe you've found Doxygen Bug 316311: 'parameter documentation after return documentation by using inline comments', which was reported in September 2005, and hasn't been fixed.
So, sadly, I'm afraid the answer to your question Is is possible to define the order so that "Parameters" will be placed before "Return"? is almost certainly No.
Edit
I've just added a note to Doxygen Bug 316311, asking for it to be changed to Status=CONFIRMED.