I'm working on a small part of a huge project. I need to change some Doxygen configuration options only for specific files. For example, there is such configuration option DOT_GRAPH_MAX_NODES and its default value is 50. I need to increase its value to 100 but only for some source files (for all other source files it should be 50). What is the the best way to achieve it?
I'm a newbie in Doxygen and I tried to #include my configuration file on a top of .cpp or try to set a new value to an option there as well but it did not help (but did not cause any warnings or errors):
/// #include MyDoxyfile
// or
/// DOT_GRAPH_MAX_NODES = 10000
I appreciate any help.
In doxygen the DOT_GRAPH_MAX_NODES is a global setting and cannot be altered. This contrary to some graphs that can be shown / hidden:
• if CALL_GRAPH is set to YES, a graphical call graph is drawn for
each function showing the functions that the function directly or
indirectly calls (see also section \callgraph and section
\hidecallgraph).
• if CALLER_GRAPH is set to YES, a graphical caller
graph is drawn for each function showing the functions that the
function is directly or indirectly called by (see also section
\callergraph and section \hidecallergraph).
and in the upcoming 1.8.15 version a similar mechanism is implemented for
REFERENCED_BY_RELATION, commands: showrefby and hiderefby
REFERENCES_RELATION, commands: showrefs and hiderefs
Related
I am building this Gtkmm3 application in Ubuntu and wanted to explore GSettings. All was going well while following the instructions at the 'Using GSettings' page and then it was time to configure the make files. I use Eclipse 2019-12 IDE with CDT (V9.10) and 'GNU Make Builder' as the builder. I'm totally perplexed as to how to introduce the macros listed in the GNOME page into the make files. I even tried changing the project to a 'C/C++ Autotools Project' using Eclipse but still the necessary make files to add the macros were missing. Creating a new project with GNU Autotools does create the necessary make files but I was not able to get pkg-config to work with it.
Can anyone point me to some resource which explains how to compile the schema and how & where to load the resultant binary file (externally if necessary). I'll consider myself blessed if someone has already made a Gtkmm3 C++ application with GSettings support using Eclipse IDE in Linux and can share the details.
Finally I figured. Thought I'll share my findings here. Actually some one out there had explained this for python (link below).
Using GSettings with Python/PyGObject
Creating the schema
For the developer the work starts with defining a schema for the settings. A schema is an XML file that looks something like this.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE schemalist SYSTEM "gio_gschema.dtd" >
<schemalist>
<schema id="org.gtk.skanray.emlibrary"
path="/org/skanray/emlibrary/" gettext-domain="emlibrary">
<key name="wave-pressure-ptrach-visible" type="b">
<default>true</default>
<summary>Set visibility of 'Ptrach' trace in pressure waveform.</summary>
<description>The pressure waveform shows multiple traces where 'PAW' is always enabled and additionally 'Ptrach' can be displayed. This settings affects the visibility of the trachial pressure trace shown in this waveform channel.</description></key>
</schema>
</schemalist>
The file name has to have a ‘.gschema.xml’ suffix. The schema file should be in the project path, only so that it gets pushed to SVN.
Best would be to use an XML editor (e.g. Eclipse) that supports design of XML files from a DTD file. Use following DTD file.
gschema.dtd
It is possible to store anything derived from GVariant into GSettings. Refer to following page to understand the basic types and the ‘type’ attribute to be used in the schema.
GVariant Format Strings
Compiling the schema
With the schema ready, (sudo) copy it into /usr/share/glib-2.0/schemas/ then run,
> sudo glib-compile-schemas /usr/share/glib-2.0/schemas/
At this point, the newly added settings can be seen / modified using dconf editor.
Accessing GSettings from the application
Coming to the main event of the show, this is how an application can read ( and / or write) settings. It is not necessary that one needs to bind property of an object to a ‘key’ in GSettings, it may be queried and used as well. Refer to GSettings API reference for details.
Glib::RefPtr <Gio::Settings> refSettings = Gio::Settings::create(“org.gtk.skanray.emlibrary”);
CLineTrace * pTrace = NULL; // CLineTrace is derived from Gtk::Widget
…
pTrace = …
…
if(refSettings)
{
refSettings->bind("wave-pressure-ptrach-visible",
pTrace,
"visible",
Gio::SETTINGS_BIND_DEFAULT);
}
Now you can fire up dconf editor and test the settings.
NOTE
Bindings are usually preferred to be made in class constructors. However binding to ‘visible’ property of a widget could be a bit tricky. Typically the top level window does a show_all() as the last line in its constructor. However constructors of the children of top level window would have completed executing including making the bindings. If there were settings that had stored ‘visibility’ as false then the top level window’s call to show_all() would mess up with that setting. In such cases it is advised to perform the bind one time in the on_map() handler of the respective class.
As I can see read is not native
>> native? :read
== false
but when I tried to get the source code with
write-clipboard mold :read
I only got header of read
make action! [[
"Reads from a file, URL, or other port"
source [file! url!]
/part {Partial read a given number of units (source relative)}
length [number!]
/seek "Read from a specific position (source relative)"
index [number!]
/binary "Preserves contents exactly"
/lines "Convert to block of strings"
/info
/as {Read with the specified encoding, default is 'UTF-8}
encoding [word!]
]]
Can I get the rest body somehow ?
The source code of native! and action! values is written in Red/System and part of the low-level runtime library code. They are not implemented in Red itself for sake of performance or because they require access to low-level features not available at Red level. Natives source code have a single entry point which you can find in the runtime/natives.reds file. For actions, it is more complex as they delegate their implementation to each datatype. Actions are basically methods for the datatype classes.
What would be best way to conditionalize text (not code).
There are 3 levels of documentation that I want conditionalized and tagged as:
Developer – This would be documentation that I don’t want doxygen to output at all. Such as notes to developers.
Internal – Information visible only for internal versions of documentation.
NDA - Information for customers plus anything not tagged as Developer or Internal; a subset of the Internal docs and would filter out internal websites for example.
There are a number of doxygen commands and configuration options which will help you achieve this. These include \internal and \endinternal. From the doxygen manual:
\internal This command starts a documentation fragment that is meant for internal use only.
You can use INTERNAL_DOCS in the config file to show (YES) or hide (NO) the internal documentation.
To address the three versions of documentation you want:
Developer: Use standard C/C++ comments, /* ... */. These won't be touched by doxygen.
Internal: For documentation only for internal use, use doxygen comments, /** ... */, and wrap these parts of the documentation with the \internal and \endinternal commands. When distributing the documentation internally set the configuration file option INTERNAL_DOCS to YES when building the documentation.
NDA: For documentation visable to the customer simply use doxygen comments /** ... */ and set the configuration optionINTERNAL_DOCS to NO in the configuration file when building the documentation.
I have a large amount of code that I'm running doxygen against. To improve performance I'm trying to break it into modules and merge the result into one set of docs. I thought tag files would do the trick, but either I have it configured wrong or I'm misunderstanding how it works.
The directories are laid out:
root +
|-src+
| |-a
|
|-doc+
|-a.dox
|-main.dox
|-main.md
|-output+
|-a+
| |-html
|-main+
|-html
In addition to 'a' there are other peer directories but am starting with one.
a.dox generates output and a tag file into root/doc/output
OUTPUT_DIRECTORY=output/a
GENERATE_TAGFILE = output/a/a.tag
INPUT=../src/a
main.dox just inputs the markdown file that has a mainpage tag and refers to the other projects tag file.
OUTPUT_DIRECTORY=output/main
INPUT = main.md
TAGFILES=output/a/a.tag=output/a/html
Should this merge or link all the docs under main where I can browse 'a' globals, modules, pages, etc? Or does this only generate links to 'a' if I explicitly cross-reference a documented entity in 'a' from inside of 'main'?
If this should work, any thoughts on where my syntax is incorrect? I've tried various ways to define TAGFILES, is the output directory relative to the main.dox file? To the a.tag file? Or to the a/html directory?
If I'm off base an TAGFILES don't work this way, is there another way to merge sets of doxygen directories into one?
Thanks.
I suggest you read this topic on how I recommend to use tag files and the conditions that should apply: https://stackoverflow.com/a/8247993/784672
To answer your first question: doxygen will in general not merge the various index files together (then no performance would be gained). Although for a part you can still get external members in the index by setting ALLEXTERNALS to YES.
Doxygen will (auto)link symbols from other sources imported via a tag file. So in general you should divide your code into more or less self-contained modules/components/libraries, and if one such module depends on another, then import its tag file so that doxygen can link to the other documentation set. If you run doxygen twice (once for the tag file and once for the documentation) you can also resolve cyclic dependencies if you have them.
In my case I made a custom index page with links to all modules, and made a custom entry in the menu of each generated page that linked back to this index (see http://www.doxygen.nl/manual/customize.html#layout) how to add a user defined entry to the navigation menu/tree.
Say I've written a class in a package, called mypackage.myclass. I've written my own HTML documentation for the package and the class, and have included this within the MATLAB help browser as described in the MATLAB documentation.
I can display this HTML documentation by using the help browser to navigate directly to it, but typing doc mypackage.myclass does not display it; instead it displays some HTML documentation that is auto-generated by helpwin (which is a nice feature, but not what I want - the auto-generated documentation is too techy for my users).
How can I force doc to display my documentation, rather than the auto-generated documentation?
Equivalently:
When you run doc docTopic, inside the doc command the Java class com.mathworks.mlservices.MLHelpServices.showReferencePage(docTopic) gets called. If a reference page for docTopic exists, it displays it and returns a success value. If a reference page doesn't exist, it returns a failure value, which then causes helpwin(docTopic) to get called. Somewhere there must be some catalog that connects values of docTopic with individual reference HTML files. How can I fiddle with that catalog - or can I create one for my package?
MathWorkers and #Yair, please give me enough undocumented rope to hang myself with :)
As far as I know this is not possible and not intended by MathWorks. I don't know of an undocumented way of doing this either. As far as I remember the keywords for doc are hard-coded somewhere.
Depending on your setup you can try the following: Prepare your own doc command that uses web(..., '-helpbrowser') to display HTML pages in MATLAB's help browser:
function doc(topic)
my_topics = {
'foo', 'foo.html'
'bar', 'bar/help/intro.html'
};
for i = 1 : size(my_topics, 1)
if strcmpi(topic, my_topics{i, 1})
web(my_topics{i, 2}, '-helpbrowser');
return;
end
end
% Fall back to MATLAB's doc. Note that our doc shadows MATLAB's doc.
docs = which('doc', '-all');
old_dir = cd();
c = onCleanup(#() cd(old_dir));
cd(fileparts(docs{2}));
doc(topic);
end
If you put that function in a file doc.m and put the corresponding directory at the beginning of the MATLAB path (see help addpath) then it will be called instead of the built-in doc.
Of course you could use some other place to store your custom doc mapping (a file, for instance) or use some kind of dynamic lookup scheme.
UPDATE: As of MATLAB R2012b, the '-helpbrowser' option of web is undocumented. This is probably related to the GUI changes in that MATLAB version, which also include the help browser. web(..., '-helpbrowser') still works as intended, but that may change in future versions of MATLAB. As far as I know, there is no documented way of opening any HTML page in the help browser in R2012b.