Of course, it takes a bit of time to generate the call-graphs. In the Diagrams tab, we will have to select the Call graphs option to generate the call graphs. The Doxygen documentation page has very clear steps on how to use the wizard to generate the documentation. dot tool is a part of the Graphviz package that helps generate the call-graphs. We can use either to generate the documentation, however for newbies, the wizard will help to generate the configuration file necessary to generate the documentation To generate the call graphs, Doxygen requires the dot tool to be available in the path. Doxygen provides both the command-line version and a wizard that guides us through the documentation generation process So to understand the code first, call-graphs are a great way to understand the code flow, even if the code is poorly or even not documented. Call graphs are control flow graphs that show what all functions/methods a particular function/method calls.Īn example of a call-graph would be like the diagram below Doxygen has a great feature of generating something called call-graphs. It also supports a variety of output formats.ĭoxygen has a robust and big set of features that this article's space is too small to contain, so we will look at it from the perspective of understanding code. It supports these source languages out of the box - C/C++, Java, Python, VHDL, PHP IDL, C#, Fortran, Objective-C 2.0, and to some extent D. The beauty of Doxygen is it has features to help understand code better even if the code is not documented properly. Javadoc for example is very popular because of the way the code documentation is organized. There are other tools documentation generators too. It would be great if they had somewhere to start and understand the code that they are going to breathe through.Įnter Doxygen! Doxygen has been there for almost a quarter of a century, written by Dimitri van Heesch. Sometimes the situation is developers don't know where to begin and understanding it is, even more, a herculean task. The plight is usually for the developers who are tasked to maintain a code that is written by someone else. It would be a nightmare if the code is not documented. and is not generated when the macro is present, considering that the input for the parser is the same, based on the Preprocessor file.Going through the code and understanding it is a daunting task, especially if the code is written by someone else. What I cant understand is how the call graph is generated when there is no #if. I even wrote the TestFunction between #if 1. I also checked the output of the preprocessor and whether without or with the conditional macro, the output is the same, the parser receives the test function. There are more functions that I test and the call graph gets correctly generated. The following tags are set for doxygen: ENABLE_PREPROCESSING = YES The tested function is defined in a header file inside the same conditional macro. The problem that I am facing is that the call graph is not generated for a function implemented between conditional macro, though if I remove the macro, the graph gets generated. I am trying to generate the documentation for a C project.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |