1

Using Doxygen 1.8.7, I've been asked to remove references to two global variables from a project's output. Looking at the source (a C header file), I found that the "global variables" aren't variables at all; they're function parameters! The header file line that the "global variable" descriptions point to looks like this. (The symbol names are changed to protect the innocent.)

int someFunctionOrOther(%const char *x, %const char *y, int z);

y and z are documented as global variables. x is not.

Looking through the file, I found several other functions with parameters named y and z. Some are earlier in the file than this one; some are later. I have no clue why y and z are documented as globals; since they are, why x is not; or why they're both "defined" at this particular point in the header file.

Is Doxygen doing something correct that has totally escaped me, or is this a bug?

If it's a bug, is there any way I can work around it?

Using a later version of Doxygen is not, unfortunately, an option. Doxygen is called by another tool we use to build docs; the tool wants version 1.8.7, and only 1.8.7. Changing that is outside my authority and experience.

Jonathan Sachs
  • 613
  • 8
  • 19
  • 1
    Version 1.8.7 (April 2014), which tools is that that wants 1.8.7? The current version is 1.8.18. What is the meaning of the `%` sign? Please some a more complete example that can be used to reproduce the problem. – albert Apr 14 '20 at 20:00
  • It's an in-house tool. The '%' suppresses automatic linking to a symbol. Now that I think about it, suppressing a link is different from suppressing a definition; I shouldn't expect that to work. /// I can't give a more complete example now. Another project uses the same header file and doesn't do this, so the problem must be context-sensitive; the only "example" I could produce easily would be the whole project, which is proprietary. If we can't figure this out within a few days my deadline will be past, and I can try to put together a useful example to solve the problem for the future. – Jonathan Sachs Apr 14 '20 at 21:15
  • 1
    As it is an in-house tool I would anyway try to talk to the people who build the tool / are currently responsible to upgrade doxygen to a newer version, at least that they have a go at trying to upgrade to see where their problems would be. – albert Apr 15 '20 at 08:47

0 Answers0