I am using Doxygen to document a C++ project which is becoming bigger and bigger and I have been wondering how I could make Doxygen a build requirement for the project. In other words, I would like my build process to fail and stop if any class/method/etc. has not been successfully documented for Doxygen. I use make for building.
For example, I would like this to fail (i.e. not build):
/**
* #bbrief Oops, tag does not exist, warning is issued and hence build fails.
*/
void f()
{
// Do something...
}
/**
* #brief Main function for program X
*
* #return End of execution status.
*
* ...
*
*/
int main()
{
f();
return 0;
}
but this to build:
/**
* #brief Okay, this is fine.
*
*/
void f()
{
// Do something...
}
/**
* #brief Main function for program X
*
* #return End of execution status.
*
* ...
*
*/
int main()
{
f();
return 0;
}
I have tried searching the Internet for this kind of feature but so far have found nothing.
In most cases the documentation is generated but due to the warnings it is incomplete. I see a few possibilities:
For this purpose the configuration setting WARN_AS_ERROR is present (see: http://www.doxygen.nl/manual/config.html#cfg_warn_as_error). Possible disadvantage is that process stopes directly when a warning is encountered.
catch the warnings in a file and count them / see if the file is
empty and based on this decide whether the build was successful or
not.
Edit
As noted by #inkychris the WARN_AS_ERROR has, as of doxygen version 1.9.0, the possibility FAIL_ON_WARNINGS. From the documentation:
WARN_AS_ERROR
If the WARN_AS_ERROR tag is set to YES then doxygen will immediately stop when a warning is encountered. If the WARN_AS_ERROR tag is set to FAIL_ON_WARNINGS then doxygen will continue running as if WARN_AS_ERROR tag is set to NO, but at the end of the doxygen process doxygen will return
with a non-zero status.
Possible values are: NO, YES and FAIL_ON_WARNINGS.
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 currently generating documentation for a pure C project.
In a file utilities.h file I have this:
/**
* #defgroup LOG_LEVELS Different levels of log file granularity
*
* \addtogroup LOG_LEVELS
* #{
* Each logging routine has a mandatory parameter defining the logging level
* of the current logging function call. Only if that level is less or equal
* to one of those predefined levels by the constants given here, that call
* will actually be logged. These constants are also used to set the current
* logging level in #currentLogPrio .
**/
#define LOGPRIO_ALWAYS 0 /**< always log this, although no error */
#define LOGPRIO_FATAL 0 /**< fatal errors */
#define LOGPRIO_ALERT 100 /**< alerts */
#define LOGPRIO_CRITICAL 200 /**< critical, but not fatal errors */
#define LOGPRIO_ERROR 300 /**< normal errors */
#define LOGPRIO_WARNING 400 /**< warnings */
#define LOGPRIO_NOTICE 500 /**< notices */
#define LOGPRIO_INFO 600 /**< informational texts */
#define LOGPRIO_TRACE 700 /**< tracing */
#define LOGPRIO_DEBUG 800 /**< debugging information */
/** #} **/
In the associated utilities.c file the static variable currentLogPrio is defined:
/**
* #var currentLogPrio
* #brief Current setting of the logging level.
*
* Only if a logging routine was called with its log level parameter set to a
* value less than or equal to the current logging priority the actual call of
* a logging routine will be written to the log.
**/
static logPrio_t currentLogPrio = LOGPRIO_ALWAYS;
Now, when I run doxygen on the complete project, I get the following warning:
...
Preprocessing utilities/logUtilities.c...
Parsing file utilities/logUtilities.c...
Preprocessing utilities/logUtilities.h...
Parsing file utilities/logUtilities.h...
...
Generating code for file utilities/logUtilities.c...
Generating code for file utilities/logUtilities.h...
...
Generating docs for file utilities/logUtilities.h...
Generating call graph for function logErrcode
Generating call graph for function logMsg_alert
Generating call graph for function logMsg_always
Generating caller graph for function logMsg_always
Generating call graph for function logMsg_critical
Generating call graph for function logMsg_debug
Generating caller graph for function logMsg_debug
Generating call graph for function logMsg_error
Generating caller graph for function logMsg_error
Generating call graph for function logMsg_fatal
Generating caller graph for function logMsg_fatal
utilities/logUtilities.h:136: warning: explicit link request to 'currentLogPrio' could not be resolved
Both files are part of the doxygen documentation as you can see from doxygens output and have the #file tag included. I also know that the #var tag for the static variable is not needed, but I get the same errors with or without this tag.
So, how can I link to that static variable?
Best regards and thanks in advance
I have been having a hard time getting the #borrows tag working in JSDoc. I have been trying to get the documentation from one function and us it as documentation for a second function. But I don't seem to be able to even get a simple example working!
/**
* This is the description for funcA
*/
var funcA = function() {};
/**
* #borrows funcA as funcB
*/
var funcB = function() {};
I was expecting this to output documentation for both functions with both exactly the same. However only funcA is only has a description.
The #borrows tag doesn't seem to work directly on a symbol, but only indirectly. For example I had:
/** does amazing things */
function origFunc = function() {};
/**
* #borrows origFunc as exportedFunc
*/
exports.exportedFunc = origFunc;
but I, like you, got nothing useful in the generated doc.
That is because, it seems, that the #borrows tag operates on a container. (If you'll notice in the examples the #borrows tag is on the "util" module/namespace, not the renamed symbol.)
So this worked for me:
/** does amazing things */
function origFunc = function() {};
/**
* #borrows origFunc as exportedFunc
*/
exports = {
exportedFunc: origFunc,
}
Seems like a bug in #borrows though. (Or at least a bug in the documentation.)
I recently had a usage of it, what I was trying to do is to create a module and add some functions to it. The problem is that I don't have anything directly related to this module, since the export is just a line. Here's how I ended up with using #borrows.
/**
* A typehead with options filtered by user input.
*
* #module Typehead
* #borrows Typehead
* #borrows TypedOption
* #example
* <Typehead />
*/
export { default } from './Typehead'
In this case, Typehead will be borrowed in either Function or Classes section of module page depending on the kind of Typehead, and it will be displayed under #example render.
Note: However #borrows will add some extra entries to the system, after some experimentation, maybe #see is a better use.
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.