What part of the doxygen configuration (Doxyfile) is recommended for version control? - version-control

Doxygen does not need all configuration tags to be explicitly defined. It will fallback to the default configuration for a tag if undefined.
In a scenario where the documentation is generated with possibly (slightly) different doxygen versions, I wonder which part of the configuration file should be put under version control.
I would prefer that the configuration put in VCS was "parsed"/generated by doxygen using an existing configuration file. The generated output can be controlled with the command line options -x, -u and -s. Using the "parsed" configuration file simplifies comparisons after future updates because the order of tags and formatting is stable.
Only the differences to the default configuration (can be generated with doxygen -x [configName]).
Benefits: It is explicit, what tags should deviate from the default configuration.
Downside: In case the default configuration changes (with a new doxygen version), the resulting configuration will differ unexpectedly.
The documentation without comments (can be generated with doxygen -s -u [configName]).
Benefits: All tags are defined. Resulting configuration does not change if a default configuration changes.
Downside: Updates in the default values are not applied automatically by using a newer doxygen version. For example an update of the default value for MATHJAX_VERSION would not be applied if already explicitly defined. A workaround may be to explicitly define those tags empty which shall dynamically use the current default value. It seems to work, but I could not find evidence in the documentation that this is a feature.
Using the "full" documentation (can be generated with doxygen -u [configName]).
Benefits: Same as for -s -u. In addition to that: In case the description of a tag changes, this will be visible in VCS. This can be helpful if the meaning has changed and the configuration must be adjusted therefore.
Downsides: Same as for -s -u. In addition to that: Irrelevant changes may occur in comments. This is noise in the VCS.
So the question is: Is it recommended to version the full configuration (-u), the one without comments (-u -s) or the minimal one containing only deviations to the default configuration (-x)?
This question is based on doxygen version 1.9.3.

Use the complete documentation without comments. That is parse the existing documentation with
doxygen -s -u [configName]
Define those tags, where you want to dynamically use the current default value, as empty.
This is the most explicit documentation and not prone to noise when the comments to tags would change. It should be reasonable to assume, that the meaning of tags do not change (at least within minor version updates).

Related

How to avoid using doxygen's file command?

Doxygen has a \file command, I had a look at different code bases and it seems some projects use it, some don't.
Having to maintain this adds some overhead (needs to be corrected when splitting files up) sometimes developers forget to do it.
Is there a way to infer this, eg: use the first doxygen formatted comment in the file as the \file comment.
Otherwise what is a good rule of thumb for when to use \file or not?
Note, I tried removing this command from all files and the output changed to group information less usefully and the order of some information changed, so it does make a difference.

Cond statement doxygen does not work

I am trying to separate out internal and external documentation using the doxygen constructs of cond; but i just cant seem to get get it working. I would essentially like to exclude some files completely and not conditionally. Regardless of where i add the tag (before include, before header guards etc) , the files and source both show up.
What i have tried in vain is to take the test file from doxegen repo for
conditional test and add it to the project.
Steps to reproduce [Linux]
create a new directory.
copy paste the above file (had to rename it to .h as .c was passed over?).
generate dummy config via doxygen -g.
update Doxyfile ENABLED_SECTION = COND_ENABLED.
Run doxygen.
check html/index.html
This however is still visible in the html documentation it generates for the project. I have set the ENABLED_SECTION variable with other values , but cond_enabled function still shows up. Running the testing directory of the project (doxygen) it passes. So i am lost.
Any suggestions?
Tried with latest version 1.8.14.
Thanks!
Regarding the \cond problems (not an answer directly to the real problem you face, I think, but to long for a comment).
The mentioned file is used in the, limited, testing doxygen can do / does and the first lines contain some instructions on what to do. Furthermore there is a default Doxyfile with the tests in use. It is hard to run a separate test outside the doxygen build tree.
Regarding the remark "Running the testing directory of the project (doxygen) it passes." This is correct, here, at the moment, only testing is done against the XML output and the generated output is compared to a once created version of the XML output. No tests are done, at the moment, in respect to HTML or PDF / LaTeX. Recently the test framework has been slightly extended so in the future this should be possible (compare the xhtml and tex output, but some work has still to be done here).
The version of the parser sees the \cond in the first line (normal C comment) as a doxygen command and skips everything till the first \endcond (your friend in these cases is always doxygen -d preprocessor). I think that removing / modifying the first line will result in an already better result. There is however another hiccup for e.g. HTML output. As the function cond_enabled is not documented and EXPAND_ALL is not set to YES the function will not appear in the documentation. So best is also to add a line of documentation with the function cond_enabled.
Regarding the seen HTML problems I modified the the relevant test in doxygen slightly and pushed a proposed patch to github (pull request 714, https://github.com/doxygen/doxygen/pull/714).
Note: the problem of skipping the \cond in normal C comment is quite a bit harder to implement (seen the logical complexity of the doxygen code in pre.l and commentcnv.l.
EDIT: 2018/06/10: The push request has been integrated in the master version on github.

.gitignore rules not working

I'm in the process of building a Lemonstand site, which I'm managing via git. As such, I'm using the following .gitignore rules:
# Lemonstand
.htaccess
php.ini
boot.php
index.php
install.php
/config/*
/controllers/*
/init/*
/logs/*
/phproad/*
/temp/*
/uploaded/*
/installer_files/*
/modules/backend/*
/modules/blog/*
/modules/cms/*
/modules/core/*
/modules/session/*
/modules/shop/*
/modules/system/*
/modules/users/*
# add content_*.php if you don't want erase client changes to content
/modules/gallery/*
/modules/lddevel/*
/modules/tweak/*
(The top block I got from github, with the second block being some additional rules I added myself to avoid issues with Lemonstands updating system).
My problem is that I'm adding a custom invoice to Lemonstand, which (to cut a long story short) requires the addition of a folder and some files within /modules/shop/invoice_templates/, which I've named cm_standard.
Because this is extra to the default Lemonstand, I want to get this tracked with git, so I'm trying to use the following rule to the bottom of my gitignore file:
!/modules/shop/invoice_templates/cm_standard/*
But when I do a git add -A, it isn't picking up the files within that directory. Even if I do a git add modules/shop/invoice_templates/cm_standard/* it tells me:
The following paths are ignored by one of your .gitignore files:
modules/shop/invoice_templates
Use -f if you really want to add them.
fatal: no files added
Which further suggests I've not written the rule correctly - can anyone help? Thank you.
Ignore patterns with fewer path segments can take precedence over patterns with more path segments, so in your case /modules/shop/* is taking precedence over !/modules/shop/invoice_templates/cm_standard/*, effectively pruning the whole of /modules/shop/invoice_templates/ from the directory traversal even before it looks at the contents of !/modules/shop/invoice_templates/cm_standard. Having said that, ordering can matter too, and when it does, somewhat counter-intuitively later rules within a file take precedence over earlier ones.
This question is very similar to How do gitignore exclusion rules actually work? so I suggest you read that. Also you may find the check-ignore subcommand useful when debugging rules - I added it to git over the last few months and it just appeared in version 1.8.2 which was released a few days ago.

Making stable names for doxygen html docs pages

I need to refer to Doxygen documentation pages. The file names however are not stable as they change after every generation. My idea is to create a symlink to each HTML file created by Doxygen , having a stable and human friendly name. Have anyone tried this?
Actually, it might be very easy just to parse the annotated.html file Doxygen produces. Any documented class shows up there as a line like:
`<tr><td class="indexkey"><a class="el" href="dd/de6/a00548.html">
ImportantClass</a></td>`
The hard problem for me is that I would like to have my file names (i.e. the symlinks) be visible on my server like:
http://www.package.com/com.package.my.ImportantClass.html
[Yes, the code is in java]. So the question actually reads: "how to connect a HTML page by Doxygen with the right java class name and its package name.
You seem to have SHORT_NAMES enabled, which will indeed produce volatile names. When you set SHORT_NAMES to NO in the configuration file (the default), you will get longer names, but these are stable over multiple runs (i.e. they are based on the name, and for functions also on (a hash of) the parameters.

Suppressing Doxygen warnings

Is there a way to suppress Doxygen from giving "not documented" warnings on particular files? My project has several automatically generated code headers that cause it to throw hundreds or thousands of errors that make it difficult to sift through.
You could use suppression tags in the generated files:
//! #cond Doxygen_Suppress
code
//! #endcond
You don't need the "Doxygen_Suppress" in there, but I like it for clarity.
There are more options in the doxygen FAQ
EDIT:
Ok, I should have done my due diligence, I have an answer that is more appropriate to your situation. I believe you need to exclude the files entirely. Add this to your doxygen file:
# The EXCLUDE tag can be used to specify files and/or directories that should
# excluded from the INPUT source files. This way you can easily exclude a
# subdirectory from a directory tree whose root is specified with the INPUT tag.
EXCLUDE = abc.cpp \
abc.h
The irony is I have had this problem and solved it, then forgot all about it... Brain must be full again.
I pulled this information from the doxygen Configuration page, but if you are lazy like me, just use the gui tool (doxywizard) and go through and select all the things you want and have it save the doxyfile for you.
There's a config option for that, as stated in documentation
WARN_IF_UNDOCUMENTED
If WARN_IF_UNDOCUMENTED is set to YES, then
doxygen will generate warnings for undocumented members. If
EXTRACT_ALL is set to YES then this flag will automatically be
disabled.
In my automatically generated headers I just add the doxygen documentation into the auto-generation routine.
This means that nothing is left undocumented.
If anyone is using Eclipse, I definitely suggest to open your file (*.doxyfile) with a text editor (note that eclipse open it with "Doxyfile Editor" by default).
So:
right click on your doxyfile and select "open-with"->"text editor"
search for WARN_IF_UNDOCUMENTED (setted 'YES' by default)
change in 'NO'.
Adding tags
//! #cond Doxygen_Suppress
code
//! #endcond
if you have many classes should be boring and hard.
Documentation for other configuration's options are available here.