Im using doxygen outside of its design, but well within its capability. I have a bunch of essentially text files, appended with some doxygen tags. I am successfully generating doxygen output. However, somehow doxygen occasionally discovers what it assumes to be a variable, and proceeds to document it using surrounding text, causing a lot of confusing documentation. I cant see any direct relationship between these anomalies, only that they're reproducing the same output on each run, and what I can see is at least some are next to a ';' or a '='.
I only want doxygen to document what I've manually tagged. I am hoping to remove any occurrence of these anomalies, however I cannot alter existing text. I can only add doxygen tags, or alter the configuration file. Any ideas?
Many thanks.
Because in my particular case, I do not need any automatically generated documentation, only that which I have tagged with doxygen tags, setting
EXCLUDE_SYMBOLS = *
removes any instance of doxygen "finding" and documenting variables. This however may remove any ability to find any class declarations, namespaces or functions, however this is acceptable for me.
Related
My goal
I am trying to submit a fix to the Filebeat documentation, written in asciidoc.
Source
Currently it is not possible to recursively fetch all files in all subdirectories of a directory. However,
the /** pattern can be used to fetch all files from a predefined level of subdirectories. For example,
/var/log/**/*.log and /var/log/**/**/*.log fetch all .log files from the subdirectories and sub-subdirectories of /var/log, respectively. Note that neither fetch log files from the /var/log folder itself.
Result
From asciidoclive.com:
My problem
The /** becomes / in the output, and the words after it are unintentionally marked in bold.
My question
How do I properly escape /** in asciidoc?
This is tricky, ’cause escaping is de facto broken in Asciidoctor. :(
I know about two possible workarounds:
use passthrough: +++\**+++,
or define attribute for asterisk, e.g. :star: * and write \{star}{star}.
Yes, it sucks and it’s not easily fixable in Asciidoctor. The best option would be to implement new AsciiDoc parser based on proper grammar etc, Asciidoctor is unfortunately in very bad shape in sense of code-quality. :( (If anyone would be willing to sponsor such project, pls contact me.)
There are several doxygen commands whose purpose is to create links in the documentation (#link, #ref).
I am currently using the #ref command to create a link to a custom file, written in a language not supported by doxygen (xml).
I would like to alter this link so that it points to a precise line in the file.
Is there a doxygen command that allows to do that ?
I'm not sure that \ref or \link can do this. However, if they could, one problem of adopting this approach is that the links will become invalid if you change the contents of the file you are linking to without changing the link. This is one of the problems of separating source code and documentation.
Rather than linking to a particular line in another file why don't you include the particular part of the file you are interested in in the documentation? You could either:
include the whole file with \include (there is also \includelineno) and just reference relevant parts of it in the text (e.g. "function xxx in the code below"), or
include snippets of the file where you need to refer to them in the documentation using \snippet.
Edit: Alternatively, you could use the \dontinclude command which, together with the \line, \skip, \skipline, and \until commands allows you to include specific lines/blocks of a particular file. See the example in the \dontinclude documentation.
I'm new to Doxygen and I'm trying to document an API I am planning to open source. I'd really like to build two sets of documentation, one for end users of the API and one for those who intend to modify it. Is there a way to tag Doxygen comment blocks in a way such that I can generate "user" and "dev" documentation trees? Is there a better solution to my problem? Thanks!
Depending on how your code is structured, you might be able to get away with using two Doxygen config files each including separate source files. The "user" config file would only list the source files containing the public interface to the API, while the "dev" config file would list all source files for the whole project.
This does mean that all your interfaces (e.g. abstract base classes) will need to be documented with the user in mind, but that is usually not a problem as by definition there is unlikely to be any implementation details in an abstract base class.
All your "dev" documentation then sits in the actual classes implementing the interfaces, which are never seen by the API and can be safely omitted by the "user" Doxygen config file.
Of course if your code isn't structured this way it's not going to work, so the only solution I can think of is to fill your comments with a bunch of conditional statements.
In addition to what Malvineous already said, there is the \internal doxygen command.
\internal lets you hide or show part of the documentation by changing INTERNAL_DOCS in the Doxyfile
More information here: http://www.doxygen.nl/manual/commands.html#cmdinternal
We've got a large codebase of Java (with a smattering of Groovy mixed in) that, by and large, has no javadocs written for it.
However, much of the code is reasonably well documented in "old-school" comments scattered throughout the body.
We're now on something of a push to try and get things documented a little better - Javadocs are now being generated on a regular basis, for example. As a stopgap measure, it would be really nice if javadoc would "scrape" the body of the class (or function, or whatever) and toss all the comments within into a "stub" javadoc.
Is there a way to do that?
Sounds like a bad idea, given that javadocs typically describe purpose and usage of elements, and code body comments are (or should be) about the details of implementation.
But if you must, you clearly need to write your own custom doclet that works in concert with a java source file parser (either 3rd party or your own). For each processed class, you would first run the parser on the source file for that given java class and harvest the internal comments, and then augment the (standard) html produced by the (standard) doclet to add the code comments.
A possible strategy that would help make the resultant javadocs sensible would be to include a given method's internal comments for the javadoc for that method. Just use a 'pre' closure and append the parsed comments of the method at the end of the generic javadoc html.
I'm producing a hex file to run on an ARM processor which I want to keep below 32K. It's currently a lot larger than that and I wondered if someone might have some advice on what's the best approach to slim it down?
Here's what I've done so far
So I've run 'size' on it to determine how big the hex file is.
Then 'size' again to see how big each of the object files are that link to create the hex files. It seems the majority of the size comes from external libraries.
Then I used 'readelf' to see which functions take up the most memory.
I searched through the code to see if I could eliminate calls to those functions.
Here's where I get stuck, there's some functions which I don't call directly (e.g. _vfprintf) and I can't find what calls it so I can remove the call (as I think I don't need it).
So what are the next steps?
Response to answers:
As I can see there are functions being called which take up a lot of memory. I cannot however find what is calling it.
I want to omit those functions (if possible) but I can't find what's calling them! Could be called from any number of library functions I guess.
The linker is working as desired, I think, it only includes the relevant library files. How do you know if only the relevant functions are being included? Can you set a flag or something for that?
I'm using GCC
General list:
Make sure that you have the compiler and linker debug options disabled
Compile and link with all size options turned on (-Os in gcc)
Run strip on the executable
Generate a map file and check your function sizes. You can either get your linker to generate your map file (-M when using ld), or you can use objdump on the final executable (note that this will only work on an unstripped executable!) This won't actually fix the problem, but it will let you know of the worst offenders.
Use nm to investigate the symbols that are called from each of your object files. This should help in finding who's calling functions that you don't want called.
In the original question was a sub-question about including only relevant functions. gcc will include all functions within every object file that is used. To put that another way, if you have an object file that contains 10 functions, all 10 functions are included in your executable even if one 1 is actually called.
The standard libraries (eg. libc) will split functions into many separate object files, which are then archived. The executable is then linked against the archive.
By splitting into many object files the linker is able to include only the functions that are actually called. (this assumes that you're statically linking)
There is no reason why you can't do the same trick. Of course, you could argue that if the functions aren't called the you can probably remove them yourself.
If you're statically linking against other libraries you can run the tools listed above over them too to make sure that they're following similar rules.
Another optimization that might save you work is -ffunction-sections, -Wl,--gc-sections, assuming you're using GCC. A good toolchain will not need to be told that, though.
Explanation: GNU ld links sections, and GCC emits one section per translation unit unless you tell it otherwise. But in C++, the nodes in the dependecy graph are objects and functions.
On deeply embedded projects I always try to avoid using any standard library functions. Even simple functions like "strtol()" blow up the binary size. If possible just simply avoid those calls.
In most deeply embedded projects you don't need a versatile "printf()" or dynamic memory allocation (many controllers have 32kb or less RAM).
Instead of just using "printf()" I use a very simple custom "printf()", this function can only print numbers in hexadecimal or decimal format not more. Most data structures are preallocated at compile time.
Andrew EdgeCombe has a great list, but if you really want to scrape every last byte, sstrip is a good tool that is missing from the list and and can shave off a few more kB.
For example, when run on strip itself, it can shave off ~2kB.
From an old README (see the comments at the top of this indirect source file):
sstrip is a small utility that removes the contents at the end of an
ELF file that are not part of the program's memory image.
Most ELF executables are built with both a program header table and a
section header table. However, only the former is required in order
for the OS to load, link and execute a program. sstrip attempts to
extract the ELF header, the program header table, and its contents,
leaving everything else in the bit bucket. It can only remove parts of
the file that occur at the end, after the parts to be saved. However,
this almost always includes the section header table, and occasionally
a few random sections that are not used when running a program.
Note that due to some of the information that it removes, a sstrip'd executable is rumoured to have issues with some tools. This is discussed more in the comments of the source.
Also... for an entertaining/crazy read on how to make the smallest possible executable, this article is worth a read.
Just to double-check and document for future reference, but do you use Thumb instructions? They're 16 bit versions of the normal instructions. Sometimes you might need 2 16 bit instructions, so it won't save 50% in code space.
A decent linker should take just the functions needed. However, you might need compiler & linke settings to package functions for individual linking.
Ok so in the end I just reduced the project to it's simplest form, then slowly added files one by one until the function that I wanted to remove appeared in the 'readelf' file. Then when I had the file I commented everything out and slowly add things back in until the function popped up again. So in the end I found out what called it and removed all those calls...Now it works as desired...sweet!
Must be a better way to do it though.
To answer this specific need:
•I want to omit those functions (if possible) but I can't find what's
calling them!! Could be called from any number of library functions I
guess.
If you want to analyze your code base to see who calls what, by whom a given function is being called and things like that, there is a great tool out there called "Understand C" provided by SciTools.
https://scitools.com/
I have used it very often in the past to perform static code analysis. It can really help to determine library dependency tree. It allows to easily browse up and down the calling tree among other things.
They provide a limited time evaluation, then you must purchase a license.
You could look at something like executable compression.