2012-06-14 13 views
11

Ich möchte eine Bibliothek mit Doxygen dokumentieren. Die Dokumentation wird von zwei Klassen von Personen gelesen: Benutzern, die nur an der externen API interessiert sind und Entwicklern, die Dokumentation für alle Funktionen/Strukturen sehen möchten.Separate "interne" von "externe" Dokumentation in Doxygen

Ich würde gerne doxyfiles zu trennen, um die Dokumentation zu erstellen. Gibt es ein "Tag", das ich in einen Kommentarblock schreiben kann, um einen Kommentar als intern/extern zu markieren?

+0

Welche Sprache ist die Bibliothek? In C# zum Beispiel glaube ich, dass Doxygen "öffentliche" vs "interne" Funktionsmodifikatoren betrachten kann. – Blorgbeard

+0

Die Bibliothek ist in C geschrieben – timos

Antwort

16

Set INTERNAL_DOCS:

# The INTERNAL_DOCS tag determines if documentation 
# that is typed after a \internal command is included. If the tag is set 
# to NO (the default) then the documentation will be excluded. 
# Set it to YES to include the internal documentation. 

INTERNAL_DOCS   = NO 

In der Dokumentation Sie \internal oder @internal an, was auch immer Sie wollen Granularität (Datei, Funktion, etc.) verwenden können.

+0

Sie haben mir eine Menge Schmerzen erspart, wenn ich versuche, das gleiche zu bekommen. –

+0

das \ intern fast nie tut, was Sie denken, dass es tut. Es blendet nur die Dokumentation aus, nicht die Klassen oder Funktionen, mit denen es verwendet wird. Ich würde dringend empfehlen, die von Mad Physicist erwähnte \ cond /\ endcond in einer anderen Antwort zu verwenden. – gnash117

9

Verwenden der \ cond Befehl:

\internal (@internal) hat nur Granularität für den aktuellen Block Kommentar. Es ermöglicht es Ihnen keine Möglichkeit, eine Strukturdefinition in C

Der einfachste Weg, sich zu verstecken, dies zu tun

gesetzt wird

\ cond INTERNE

an der Spitze eines internen Header-Datei und

\ ENDCOND

an der Unterseite. Dann wird in der Konfigurationsdatei, fügen Sie

ENABLED_SECTIONS = INTERN

die inneren Elemente zu ermöglichen, in der Dokumentation enthalten sein.

Dieser Weg wird auch von Doxygen-Benutzern empfohlen, z. here

0

Dies ist eine einfache Lösung, die die Tatsache nutzt, dass Sie normalerweise die internen und externen Teile Ihres Codes in Dateien unterscheiden können.

Sie können einfach die Eingabedateien beschränken, nur die Header-Dateien, die Sie in der externen Dokumentation verfügbar machen möchten:

# For internal, we parse all files 
INPUT = ./ 
# For external, we parse only the files containing the public interface 
INPUT = include/header1.hpp include/header2.hpp 

Dies hat den Vorteil, dass die Quelldateien nicht geändert werden (mit \internal oder @internal).

Verwandte Themen