GNOME Bugzilla – Bug 509348
A function description is distributed between the source and its header file
Last modified: 2009-08-20 10:12:50 UTC
C language project A function call graph and references are put into the header file (where the function prototype with or without 'extern' keyword is located), while the caller graph and referenced by sections are put into the source file with the function definition. I haven't found any properties to influence on this behavior and consider this as a bug. Moreover, before the header file was created, the function call graph was put into another source file where the function is used (called), but not defined. It is possible to provide an example to reproduce the problem, if necessary.
Created attachment 102806 [details] The test case to reproduce the problem To reproduce the problem 1. unpack the archive 2. in the cintg.dg folder execute make doc 3. after the documentation is generated, open the index.html from the docs/html folder, open files, find and open get_token.c source file, find description of the eval_exp function: there is no call graph 4. open the file get_token.h documentation, find there eval_exp function: there is the call graph Problem: call and caller graphs must be either in both files or only in the source file, but not separated between two files.
According to the changelog this problem should have been fixed in 1.5.3-20071008, so before the 1.5.4 release. I see the call graph in the current subversion snapshot (and in 1.5.4) in both the header and the source file, so are you sure you get the problem with release 1.5.4? or did you perhaps use an older version by mistake?
The version 1.5.4. is the only version I have: bash-3.1$ doxygen --version 1.5.4
The problem is with the extra (and redundant) forward declaration in the .c file. This prevents the actual definition of the function to get the proper attributes. I'll fix this in the next release.
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.6.0. Please verify if this is indeed the case and reopen the bug if you think it is not fixed (include any additional information that you think can be relevant).