Doxygen autolink not working to global enum types - doxygen

I am trying to use Doxygen Automatic link generation to document some enum types. However, it is not generating links for the global enum types. It does generates links for the global struct types. Is there something I am missing? I am using the example provided on the link above. As required, I have documented the file in which the types are defined.
update1: I am using Doxygen version 1.6.3
update2: global structs are ok

Yeah, I had that same issue; i think doxygen thinks they are private or something stupid like that. Try using the \public. Don't forget to do the /*! on the first line
/*! \public
* Enum description goes here
*/
typedef enum {
/**
* Printer control language ZPL
*/
PRINTER_LANGUAGE_ZPL,
/**
* Printer control language CPCL
*/
PRINTER_LANGUAGE_CPCL
} PrinterLanguage;

I was having the same issue. Some header files generated a link for enums and other header files did not. You must explicitly document the file.
Here is a excerpt from this page int the documentation.
http://www.doxygen.nl/manual/docblocks.html#memberdoc
To document a global C function, typedef, enum or preprocessor
definition you must first document the file that contains it (usually
this will be a header file, because that file contains the information
that is exported to other source files).
Attention
Let's repeat that, because it is often overlooked: to document global objects (functions, typedefs, enum, macros, etc), you must
document the file in which they are defined. In other words, there
must at least be a
/*! \file */
or a
/** #file */
line in this file.

Related

Can I get Doxygen to use untagged comments, on function prototypes?

The company I'm working for does not use Doxygen, and in their coding standard explicitly prohibits "parseable comment styles such as javadoc, etc".
However, I've still found it very useful to run Doxygen myself just so I can see the class structure, and get nice per-class documentation of all the methods the a class has, including inherited ones.
The company does document the classes in the header files, with simple comments above each method declaration. It would be very useful if I could configure Doxygen to treat these comments as the function descriptions, even though they don't start with any Doxygen markers.
So: is it possible to get Doxygen to treat comments on the line above declarations as if they are the description for that item even when the comment is not marked with Doxygen's "parse this comment" markers?
The next best thing is to click on the #include <foo.h> links at the top of the class file to jump to the file itself, which I have been using. That doesn't help for seeing all of a derived class's methods in one place, though.
When the comments above the methods have only "normal" comments i.e. with /* or // the best thing to do would be that you write a small filter (see e.g. INPUT_FILTER with sed or awk or ... ) in which you convert (all?) /* / // comments into /** / /// so the comment blocks are parsed by doxygen. The result is not as nice as with "full" doxygen comments.
It is just a workaround and can lead to unexpected results when the INPUT_FILTER does not exclude e.g. // inside strings from consideration.

Doxygen: specify layout per file

I would like to change the page layout for a single source file. The other pages should be generated as before.
Other option would be to generate a seperate page referencing the relevant content from that source file.
To make it a little more concrete, I have the following file and would like to generate a documentation file only including these comments without the printing of includes, etc.
And as said this behavior is only intended for this single source file.
/**
* TreeNode
*xxx
*/
class TreeNode
/**
* TreeNode2
*xxx
*/
class TreeNode2
Thanks a lot!
I think your best approach is to exclude the bits you don't want by surrounding those parts in the file with #cond and #endcond markers. (The #if 0 of doxygen.)
In that way your file processing won't be complicated with file-specific layouts (which I'm not sure is possible anyway) and the 'special' handling of that file is visible within that file's content.

Doxygen - Expand macros but ignore #if?

Is it possible to tell Doxygen to expand macros but ignore other preprocessor directives?
Take the following into account:
#if defined(linux)
#define OS_LINUX
int function() { /* ... */ }
// Other functions defined for Linux
#elif defined(__WIN32__)
#define OS_WINDOWS
int function() { /* ... */ }
// Other functions defined for Windows
#else
#error "OS unsupported."
#endif
In this case, I want the functions for both Windows and Linux to show up, but I also want the macros OS_LINUX and OS_WINDOWS to show up in the documentation as well. Is there a way to document both macros while ignoring the #ifs?
No, you cannot do that you will have to build the documentation for each configuration separately. However if both Windows and Linux have the same interfaces defined, the documentation will surely be the same for both functions in any case?
By default if Doxygen finds documentation for a declaration in a header and documentation for corresponding definitions in source-files, the documentation in the header will be used. In this case you can use this to your advantage by only placing Doxygen mark-up in the header files. Normally the interfaces will be identical cross-platform and you will have a single header, but multiple implementations for each platform, either in separate sources or using conditional compilation.

How to manage a Doxygen project with multiple libraries?

I'm working on a project that uses multiple libraries, set up in a structure like so:
/src
/libs/libOne
/libs/libTwo
I want to generate a single Doxygen page which covers all my code as well as the libraries. This was quite simple by just pointing Doxygen at the root. However, I want the doxygen output to be grouped so I can clearly see which library each class/file belongs to. However, since the libraries are not written by me I don't want to change them to add \addtogroup comments.
I don't mind if the produced documentation is subpar for the libraries (for example if they don't include doxy compatible comments), I still want them included so I can view call graphs, and quickly browse the classes, etc.
How can I group each libraries code into modules without changing the libraries' source?
thanks
You should put all the necessary documentation in external files. I didn't know how to do this, but I've tried to set up a minimal environment like yours and it worked well. Just for documenting something I've grabbed the example code on the Doxygen site:
test1.h:
#define MAX(a,b) (((a)>(b))?(a):(b))
typedef unsigned int UINT32;
int errno;
int open(const char *,int);
int close(int);
size_t write(int,const char *, size_t);
int read(int,char *,size_t);
and wrote the totally useless test2.h (just to have two different files...):
void itdoesnothing();
Here comes the nice part. I've made an external header just for documenting the above, called it test_doc.h (again, just used the example on the Doxygen site):
/*! \addtogroup everything The main group
This group contains everything.
#{
*/
/*! \file test.h
\brief A Documented file.
Details.
*/
/*! \def MAX(a,b)
\brief A macro that returns the maximum of \a a and \a b.
Details.
*/
/*! \var typedef unsigned int UINT32
\brief A type definition for a .
Details.
*/
/*! \addtogroup err Error handling
Error handling related stuff
#{
*/
/*! \var int errno
\brief Contains the last error code.
\warning Not thread safe!
*/
/*! #} */
/*! \addtogroup fdrelated File description related
File descriptor related stuff.
#{
*/
/*! \fn int open(const char *pathname,int flags)
\brief Opens a file descriptor.
\param pathname The name of the descriptor.
\param flags Opening flags.
*/
/*! \fn int close(int fd)
\brief Closes the file descriptor \a fd.
\param fd The descriptor to close.
*/
This successfully documented both files for Doxygen. This way you can group files, namespaces etc. too, as stated in the manual:
Members of a group can be files, namespaces, classes, functions, variables, enums, typedefs, and defines, but also other groups.
So try reading http://www.doxygen.nl/grouping.html too and see what's possible to do with the things I've mentioned above. Good luck!

Exclude some classes from doxygen documentation

I am building a Qt based project, and many Qt classes are found in the target documentation.
How can I tell Doxygen to disable documentation generation for some classes? For Q.*?
Working under the assumption that what you have is something like this: (The question is a little unclear in this regard)
/**
* Some documentation for class X
*/
class X: public osg::Drawable {
...
}
And your problem is that you want to include documentation for class X, but not for class osg::Drawable, the proper technique is to use EXCLUDE_SYMBOLS. For example, in the case above use
EXCLUDE_SYMBOLS = osg::Drawable
If you want to be slightly more rigorous, you can use
EXCLUDE_SYMBOLS = osg::Drawable \
Drawable
Wild-cards are also allowed, so this will also work
EXCLUDE_SYMBOLS = osg::*
If \internal tag does not work, you can try \cond ... \endcond tags for marking a portion of code to be hidden from Doxygen.
EDIT
If you want to exclude specific files, you can use EXCLUDE_PATTERNS variable in Doxyfile configuration file.
Its not the best way but one can mark some portion of the documentation (class, members, ...) with the private. This prevents the piece of code from being included in the output documentation. (I use this to hide copy/move constructors/operators from appearing in the API documentation.)
/*!
* \brief This is included.
*/
class API
{
public:
/*!
* \brief So is this.
*/
API() noexcept;
/// \private
~API() noexcept; /* But this not, though technically public. */
private:
int m_version; /* This is not either. */
}
One should note though that this is a Doxygen extension for PHP, which according to the documentation they should not be used.
For PHP files there are a number of additional commands, that can be used inside classes to make members public, private, or protected even though the language itself doesn't support this notion.
The other option is to use the solution mouviciel provided, but it requires at least two lines.
Though not the correct answer for the detailed question it might be helpful for readers of the question title (like me). It works for classe too!