How to add files without extension in doxygen configuration file(e.g iostream library)? - doxygen

In my configuration file in the INPUT tag I added one directory. Inside that iostream is there without any extension. After running the configuration file I'm not getting information related to iostream. I want to know how to add the files without extension in doxygen configuration file.

I created a small test example (contents is not that relevant for this test), file stdio:
/// the fie
void fie(void);
From the documentation (https://www.doxygen.nl/manual/config.html#cfg_extension_mapping):
EXTENSION_MAPPING
Doxygen selects the parser to use depending on the extension of the files it parses.
With this tag you can assign which parser to use for a given extension. Doxygen has a built-in mapping, but you can override or extend it using this tag. The format is ext=language, where ext is a file extension, and language is one of the parsers supported by doxygen: IDL, Java, JavaScript, Csharp (C#), C, C++, D, PHP, md (Markdown), Objective-C, Python, Slice, VHDL, Fortran (fixed format Fortran: FortranFixed, free formatted Fortran: FortranFree, unknown formatted Fortran: Fortran. In the later case the parser tries to guess whether the code is fixed or free formatted code, this is the default for Fortran type files).
For instance to make doxygen treat .inc files as Fortran files (default is PHP), and .f files as C (default is Fortran), use: inc=Fortran f=C.
Note: For files without extension you can use no_extension as a placeholder.
Note that for custom extensions you also need to set FILE_PATTERNS otherwise the files are not read by doxygen.
Here we see that the possibility for no_extension and with the following setting we get the requested information:
EXTRACT_ALL=YES
INPUT = stdio
EXTENSION_MAPPING = no_extension=C++
and I do see the stdio information.
Edit
In case doesn't want to add all files one by one one hast to add * to FILE_PATTERNS.

Related

Unix file associations of mime-type with multiple extensions

Unix File Associations is a welcome new feature in install4j 8.
I'm trying to register multiple file extensions as file associations with the same mime-type with the install4j 8.0.1 Unix Shell Installer.
The "Create a File Association" action only seems to accept one file extension so I initially tried adding multiple of these actions with a different extension but the same mime-type. This seems valid, but when it translates into the actual installation of the application it appears that the mime-info XML files being made are named with the same mime-type and so all but one get overwritten. This leads to only one file extension being associated with the mime-type.
I've also tried various separators (space, comma, semi-colon) in the file extension field, but this just ends up as a single unlikely looking extension in the mime-info XML file!
(e.g.
<glob pattern="*.ext1,ext2" weight="60"/>
)
The mime-info XML format allows multiple <glob> elements, so the mime-info XML file could contain, e.g.
<glob pattern=".ext1" weight="60"/>
<glob pattern=".ext2" weight="60"/>
but I can't see a way to get to this from install4j8.
Is there a way?
As of 8.0.1, this is indeed not possible. In 8.0.2, you will be able to specify multiple extensions separated by commas. Please contact support#ej-technologies.com to get a build where this is already implemented.

Indicate language for doxygen \include

I am trying to include a .ini file in the doxygen documentation of a C++ class, using \include. This works fine, but for some reason, doxygen treats the contents of the file as C code, which leads to strange formatting. I know \include surrounds the included file with a \code block, and that you can pass specific language information to the code block by using e.g. \code{.unparsed}. Is there a way to do the same with \include? \include{.unparsed} does not work...
Seems the answer to the question is "no": you cannot indicate a language when using \include, since doxygen tries to determine the language based on the extension. If it fails to do so, it reverts to C. If you do not want C formatting for unsupported file extensions, you can use \verbinclude instead of \include.

How to ignore generated code in doxygen

So, we are using doxygen in a big project.
Some of the source code is generated during the build,
like my_generated_code_fragment.h
It is used in the source code, like this
file foo.cc
void foo()
{
#include "my_generated_code_fragment.h"
}
Now, when running doxygen from the repository under source control,
doxygen rightly complain that file my_generated_code_fragment.h is missing,
with an error like:
foo.cc:1234: warning: include file my_generated_code_fragment.h not
found, perhaps you forgot to add its directory to INCLUDE_PATH?
Problem
We don't want to perform a full build first, just to generate the missing
files, in order to generate documentation.
Note that the generated code does not contain doxygen comments anyway.
Solution considered so far
Do Nothing
Do nothing and ignore doxygen errors.
Not really satisfactory.
Generate dummy files
Generate dummy files like my_generated_code_fragment.h prior to running
doxygen.
This creates complications in the build scripts,
where "using doxygen" is now different on different projects,
because the files containing generated code differs.
Use preprocessor flags
Change the code to
void foo()
{
#ifndef IN_DOXYGEN
#include "my_generated_code_fragment.h"
#undef IN_DOXYGEN
}
and set PREDEFINED
This is the best solution considered so far, but it means changing the code.
Question
Is there a better option, like tell doxygen using a setting in Doxyfile
that file my_generated_code_fragment.h is expected to be missing,
and should be ignored ?
Note:
EXCLUDE does not work for this,
as the error is seen when parsing file foo.cc, not when parsing the generated code.
Using doxygen version 1.8.5 at the moment.
Documenting the solution taken then.
Solution 3, to use pre-processor flags when building with doxygen, and changing the (small) parts of the code that uses generated content worked well.
This allows to use doxygen on "raw" source code, pulled from git.

Doxygen does not process my source file comments

I'm new with Doxygen, and i have been commenting my functions with the Qt style approach:
/*! .. */
Doxygen however only picks up my header files and does not generate documentation of any text that is within these comments.
The html file rendered, shows a completely empty main page, "Classes' only list the structs
that are found in the header files and "Files" lists only the same header files in the project.
What may cause this behavior, or is this to be expected?
Am i missing something? The only thing i changed in the configuration file was the INPUT directory to be "src".
No errors during compilation, i see that it is preprocessing and parsing my .c files. And at some point it says this, but only for the header files
Generating code for file src/foo.h...
Generating code for file src/bar.h...
etc.
Finally i get some warnings about structs not being documented, but nothing about the functions I want to have actually documented.

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.