I'm trying to use Doxygen, but I can't make it work with my code. In a nutshell, if it contains #include's Doxygen just ignores it. This is a MWE:
/*!
\file
\brief This foos bars
\author John doe
*/
#include <stdio.h>
#include <stdlib.h>
/*!
\brief print a net.
This prints nets.
\param net Net to print.
*/
void printf_net(int8_t* net){
printf("%d\n",L);
for(int i=0;i<L*L*L;i++){
printf("%d\n",net[i]);
}
}
If I comment the #include's, documentation is generated for the function, but not with them. What should I correct in my code?
Updates:
In response to the comments,
Using /** instead of /*! doesn't seem to change the behaivour.
I have ENABLE_PREPROCESSING = YES in my Doxyfile. Basically, I have all the default values of the graphical wizard.
I'm using Doxygen 1.8.12
UPDATE:
I was enabling HAVE_DOT by accident. Disabling that option fixes my problem.
Related
I have noticed, that when using Doxygen to document a .c file, the list of includes in the given file is also included in the output, for instance:
https://agnix.sourceforge.net/documentation/api/bridge_8c.html
Now, what I typically do, is include some general comments before a given "include block" ("intro comments"), and then some specific comments on the same line as the include line:
...
/*
* The following includes are required for
* the code to compile:
*/
#include <stdio.h> // contains printf()
#include <netinet/in.h> // contains sockaddr_in
...
Is it possible to have these kinds of comments formatted for Doxygen, (either "intro comments", or "on same line" - hopefully both), such that I get them output in the final documentation for that .C file?
Essentially, for the above example, I'd get an output like this (screenshot is from manually hacked HTML, to get a mock-up of desired output):
(I guess, this could be seen as a somewhat of a "literal programming" approach)
If you want Doxygen recognizes a file to insert it in documentation, you should use
/** <- (this format is recognized by Doxygen)
* #file name_of_file.h
*
* #brief What is
*
* #author You
*
* #date 03/01/2023
*
* #par Put the title of the paragraph
* Write the content of the paragraph
*/
at the beginning of your header file (note: #file is mandatory).
Read also Doxygen guide
I'm trying to compile my first GStreamer plugin with Visual Studio 2013 (v120). But when I'm trying to init GValue type list
g_value_init (&va, GST_TYPE_LIST);
I get
error LNK2001: unresolved external symbol _gst_value_list_type
I found out that _gst_value_list_type is defined like this
extern GType _gst_value_list_type;
/**
* GST_TYPE_LIST:
*
* a #GValue type that represents an unordered list of #GValue values. This
* is used for example to express a list of possible values for a field in
* a caps structure, like a list of possible sample rates, of which only one
* will be chosen in the end. This means that all values in the list are
* meaningful on their own.
*
* Returns: the #GType of GstValueList (which is not explicitly typed)
*/
#define GST_TYPE_LIST (_gst_value_list_type)
but I have no idea where to find it
I have correct header files included and I have tried to link every lib there is from gstreamers but without any success. I'm using last version of gstreamer downloaded from here
Try to include
#include <gst/gstconfig.h>
#include <gst/gstcaps.h>
#include <gst/gststructure.h>
#include <gst/gstcapsfeatures.h>
#include <gst/gst.h>
One by one. Please answer if its helps.
I think when you compile, your include path see different area.
in my case, i have two gstreamer include path
(/usr/include/gstreamer-1.0 and /usr/local/include/gstreamer-1.0)
in the /usr/include/gstreamer-1.0
GST_TYPE_LIST is defined below
#define GST_TYPE_LIST gst_value_list_get_type()
in the /usr/local/include/gstreamer-1.0
GST_TYPE_LIST is defined below
#define GST_TYPE_LIST (_gst_value_list_type)
After changing include path to /usr/include/gstreamer-1.0, I solve the problem.
This issue is due to doxygen parsing constraints. I am using doxygen 1.8.11 with Eclox (the eclipse plugin) in Kinetis Design Studio for embedded C development.
Almost all of the doxygen compiling works, except I need to have a few very large static arrays. I didn't want to clutter up the main code, so I used a hack I found on these forums (https://stackoverflow.com/a/4645515/6776259):
static const float Large_Array[2000] = {
#include "Comma_Delimited_Text_File.txt"
};
Unfortunately, that hack is causing the compile of my main.c main_module group to fail. With the following error:
warning: end of file while inside a group
I've tried excluding those constants from my main_module group with something like the following:
/*!
** #addtogroup main_module
** #{
*/
...
... header code ...
...
/*!
** #}
*/
static const float Large_Array[2000] = {
#include "Comma_Delimited_Text_File.txt"
};
/*!
** #addtogroup main_module
** #{
*/
...
More code, definitions, etc.
None of this is generated in the doxygen compile...?
/*!
** #}
*/
This gets rid of the doxygen compiling error, but the compiled doxygen documentation does not include anything after the Large_Array declaration. So it seems the second #addtogroup statement is not working.
Am I missing something simple? Any help is appreciated. Thank you.
If Comma_Delimited_Text_File.txt doesn't have trailing linebreak, then try adding one.
Doxygen gets confused if include file doesn't end with linebreak. This can break the document generation for other files too, even when they don't seem related. Often this results in missing symbols and broken callgraphs.
I have ran into a problem with eclipse cdt 3.8.0 formatter on debian. when it formats my code automatically the newline between functions returning bool and block comments is removed like the follow:
this a problem in C source files and only applies to bool type
please help me correct this problem:
#include <stdbool.h>
/* my comment 1 */
void foo(void);
/* my comment 2 */bool is_valid(void);
/* my comment 3 */
int cool(void);
and I want this:
#include <stdbool.h>
/* my comment 1 */
void foo(void);
/* my comment 2 */
bool is_valid(void);
/* my comment 3 */
int cool(void);
When I comment #include <stdbool.h> and insert the following codes. the formatter act correctly
typedef int bool;
#define true 1
#define false 0
ofcourse when I insert the following codes instead of above code the problem still remains.
#define bool int
#define true 1
#define false 0
It seems that the formmater not acts correctly for Macros
I find a solution, however it is not a complete answer.
I noticed that it is a bug for eclipse cdt formatter not understanding bool type.
but when I use double slash comments instead of slash star comments the formatter does not join the two lines and since double slash comments are introduced in C99 it will work there.
/* my comment 1 */
void foo(void);
// my comment 2
bool is_valid(void);
/* my comment 3 */
int cool(void);
of course I think the above problem needs to be reported to the eclipse DEV team. does any one knows where it should be reported?
Old thread, but I ran into a similar problem related to the c99 bool and stdbool.h. The cdt project settings have a definition for the __cplusplus macro by default, which is used by stdbool.h to NOT define bool/true/false if the code is C++. Just delete that in project properties under "C/C++ Include Paths and Preprocessor Symbols".
I couldn't find any entry in eclipse's menu that allow you to configure line wrapping for function prototypes.
I can only suggest you to use the search and replace within the eclipse, select all lines you want to edit, press CTRL+F, fill the search dialog with */ in the search field and */\n in the replace field, check the 'regular expressions' box and click replace all.
I have some includes in the source code where I want to add some "to do".
For example:
/** \todo Review. */
#include "anyfile.h"
/** todo Another to do. */
#define ANY_MACRO 1
The problem is that the first "to do" is inserted in the macro definition and not in the include, as followed:
-----------------------------------
**Todo List**
Global **ANY_MACRO**
Review.
Another to do.
-----------------------------------
Any idea how to solve this ?
Following the online doc:
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.
Then I handle your problem in the following manner: I must have a \file comment in both files, and above the include line, I mention that the todo part refers to the included file.
In other words, I write this in my source file afile.c:
/** \file anyfile.h
* \todo Review
*/
#include "anyfile.h"
/** \file afile.c
* \brief Some code
*/
/** \todo wait, a todo !*/
#define A_MACRO
int main()
{}
In the included file, I write a short comment about the file itself:
/** \file anyfile.h
* Very interesting header
*/
#define B_MACRO
As output, the todo comment is placed in the doc page of the included file. The awkward part according to me is that I have to put the block /** \file afile.c */ after the include line, otherwise it doesn't work.