views:

39

answers:

2

Is there a way to suppress Doxygen from giving "not documented" warnings on particular files? My project has several automatically generated code headers that cause it to throw hundreds or thousands of errors that make it difficult to sift through.

A: 

http://www.stack.nl/~dimitri/doxygen/config.html#cfg_warn_if_undocumented

Mchl
Can I give it any sort of scope so it warns for my files and ignores others?
Nick T
Hmmm.. doesn't look like you can. It's possible to exclude files entirely, but not to selectively supress warnings... :(
Mchl
+1  A: 

You could use suppression tags in the generated files:

//! @cond Doxygen_Suppress
code
//! @endcond

You don't need the "Doxygen_Suppress" in there, but I like it for clarity.

There are more options in the doxygen FAQ

EDIT: Ok, I should have done my due diligence, I have an answer that is more appropriate to your situation. I believe you need to exclude the files entirely. Add this to your doxygen file:

# The EXCLUDE tag can be used to specify files and/or directories that should 
# excluded from the INPUT source files. This way you can easily exclude a 
# subdirectory from a directory tree whose root is specified with the INPUT tag.

EXCLUDE                = abc.cpp \
                         abc.h

The irony is I have had this problem and solved it, then forgot all about it... Brain must be full again.

I pulled this information from the doxygen Configuration page, but if you are lazy like me, just use the gui tool (doxywizard) and go through and select all the things you want and have it save the doxyfile for you.

SuperJames
The generated files are blown away and recreated every time I make any changes to the project settings. The tool allows me to insert comments into the generated files, but they're all in a block, though open `\cond`s seem to work. The worst offenders though (an IO map header that lists *every single register and bit field of the processor*) I can't do that with.
Nick T
The open tags seem to be interfering with some of my code's documentation on second glance; `#defines` notably, but mostly documentation in the headers.
Nick T

related questions