autogsdoc - GNUstep API-Dokumentationsgenerator und XML->HTML-Konverter
autogsdoc [-Files filename] [-GenerateHtml YES|no] [-Clean yes|NO] [-CleanTemplates yes|NO] [-IgnoreDependencies yes|NO] [-MakeDependencies yes|NO] [-ShowDependencies yes|NO] [-HeaderDirectory path] [-DocumentationDirectory path] [-Declared location] [-Project title] [-Standards yes|NO] [-DocumentAllInstanceVariables yes|NO] [-DocumentInstanceVariables YES|no] [-InstanceVariablesAtEnd yes|NO] [-ConstantsTemplate filename] [-FunctionsTemplate filename] [-MacrosTemplate filename] [-TypedefsTemplate filename] [-VariablesTemplate filename] [-SystemProjects string] [-LocalProjects string] [-Projects dictString] [-Verbose yes|NO] [-Warn yes|NO] [-WordMap dictString] [files]
Das Autogsdoc-Tool ist ein Befehlszeilendienstprogramm, das Entwicklern hilft, Referenzdokumentation für GNUstep-APIs zu erstellen. Es ermöglicht Entwicklern außerdem, andere Dokumentationen in XML zu schreiben und zu verwalten und diese in HTML konvertieren zu lassen. Im Detail wird autogsdoc:
Extrahieren Sie spezielle Kommentare, die die öffentlichen Schnittstellen von Klassen, Kategorien, Protokollen, Funktionen und Makros beschreiben, aus dem Objective-C-Quellcode (Header-Dateien und optional Quelldateien) in GSDoc-XML-Dateien.
Konvertieren Sie GSDoc-XML-Dateien, unabhängig davon, ob sie aus Quellcode generiert oder manuell von Entwicklern geschrieben wurden, in HTML.
Erstellen Sie Indizes basierend auf GSDoc-XML-Dateisätzen und konvertieren Sie diese auch in HTML.
Die häufigste Verwendung besteht darin, den Befehl mit einem oder mehreren Header-Dateinamen als Argumenten auszuführen. Das Tool analysiert automatisch die entsprechenden Quelldateien im selben Verzeichnis wie die Header (oder im aktuellen Verzeichnis oder in dem mit dem DocumentationDirectory angegebenen Verzeichnis). Standard) und erzeugen GSDoc- und HTML-Dateien als Ausgabe. Um optimale Ergebnisse zu erzielen, sollte dieser Modus aus dem Verzeichnis ausgeführt werden, das die Quelldateien enthält. (Beachten Sie, dass dieses Tool Funktionen und andere C-Strukturen in einfachen C-Quellen dokumentieren kann, da C eine Teilmenge von Objective C ist.)
GSDoc-Dateien können auch direkt zusätzlich oder einzeln angegeben werden und werden in HTML konvertiert. Informationen zum GSDoc-Format finden Sie in der GSDoc-HTML-Dokumentation oder auf der Manpage gsdoc(7).
Schließlich können HTML-Dateien auf der Befehlszeile angegeben werden. Querverweise auf andere darin enthaltene Teile der Codedokumentation werden basierend auf dem, was derzeit im Projekt gefunden wird, neu geschrieben.
Der Quellcode-Parser erstellt automatisch GSDoc-Dokumente, in denen die Methoden in den in den Quelldateien gefundenen Klassen aufgeführt sind, und enthält Text aus speziell formatierten Kommentaren aus den Quelldateien.
Jeder Kommentar, der mit einem Schrägstrich und zwei Sternchen anstelle des üblichen Schrägstrichs und eines einzelnen Sternchens beginnt, wird als GSDoc-Markup betrachtet und als Beschreibung der darauf folgenden Klasse oder Methode verwendet. Dieser Kommentartext wird neu formatiert und dann in die Ausgabe eingefügt.
Wenn mehrere Kommentare mit demselben Element verknüpft sind, werden sie bei Bedarf mit einem Zeilenumbruch (
) zwischen den einzelnen Kommentaren verbunden.Das Tool kann problemlos zum Dokumentieren von Programmen und Bibliotheken verwendet werden, indem man ihm einfach den Namen der Quelldatei gibt, die die main()-Funktion des Programms enthält – es übernimmt die speziellen Kommentare von dieser Funktion, behandelt sie speziell und fügt sie als ein ein Abschnitt am Ende des ersten Kapitels des Dokuments (erstellt ggf. das erste Kapitel).
Optionen werden im Abschnitt Argumente und Standardeinstellungen unten beschrieben.
In einigen Fällen wird eine spezielle Zusatzverarbeitung durchgeführt, vor allem im ersten Kommentar in der Quelldatei, aus dem verschiedene Teile des GSDoc-Markups extrahiert und an geeigneten Stellen im Ausgabedokument platziert werden können –
In jeder Zeile, in der AutogsdocSource: gefunden wird, wird der Rest der Zeile als zu verwendender Quelldateiname verwendet, anstatt davon auszugehen, dass jede verarbeitete .h-Datei eine .m-Datei derselben verwendet Name. Sie können mehrere AutogsdocSource:-Zeilen angeben, in denen eine Header-Datei Elemente deklariert, die in mehreren Quelldateien definiert sind. Wenn ein Dateiname absolut ist, wird er wie angegeben verwendet. Wenn es sich hingegen um einen relativen Pfad handelt, sucht die Software zunächst relativ zum Speicherort der Header-Datei nach der Quelldatei. Wenn sie dort nicht gefunden wird, relativ zum aktuellen Verzeichnis, in dem autogsdoc ausgeführt wird, und schließlich relativ zu das durch die Standardeinstellung DocumentationDirectory angegebene Verzeichnis.
Eine Zusammenfassung des Inhalts des Dokuments ... im Kopf der GSDoc-Ausgabe platziert.
Eine Beschreibung des Autors des Codes – kann wiederholt werden, um den Fall zu behandeln, dass ein Dokument mehrere Autoren hat. Wird im Kopf der GSDoc-Ausgabe platziert. Um die Lesbarkeit der Quelle zu verbessern, werden einige spezielle zusätzliche Verarbeitungen in Bezug auf den Dokumentautor durchgeführt – jede Zeile des Formulars
Name
Name
Name‘ bzw
„name“ wird erkannt und in ein author-Element umgewandelt, das möglicherweise ein email-Element enthält.
Wird in der GSDoc-Ausgabe direkt vor dem Ende des Hauptteils des Dokuments platziert – zur Verwendung für Anhänge, Index usw. vorgesehen.
Wird unmittelbar vor jeder generierten Klassendokumentation platziert ... und soll dazu dienen, eine Gesamtbeschreibung der Funktionsweise des zu dokumentierenden Codes bereitzustellen. Jegliche Dokumentation zur main()-Funktion eines Programms wird als Abschnitt am Ende dieses Kapitels eingefügt.
Urheberrecht des Inhalts des Dokuments ... im Kopf der GSDoc-Ausgabe platziert. Um die Lesbarkeit der Quelle zu verbessern, wird eine spezielle zusätzliche Verarbeitung durchgeführt: Jede Zeile der Form „Copyright (C)-Text“ wird erkannt und in ein copy-Element konvertiert.
Datum der Überarbeitung des Dokuments ... im Kopf der GSDoc-Ausgabe platziert. Wenn dies weggelassen wird, versucht das Tool, einen Wert aus dem RCS-Datums-Tag zu erstellen (falls verfügbar).
Wird am Anfang des Hauptteils des Dokuments eingefügt ... soll als Einleitung, Inhaltsseite usw. dienen.
Titel des Dokuments ... im Kopf der GSDoc-Ausgabe platziert. Wenn dies weggelassen wird, generiert das Tool einen eigenen (wahrscheinlich schlechten) Titel – Sie sollten dieses Markup daher manuell einfügen.
Versionskennung des Dokuments ... im Kopf der GSDoc-Ausgabe platziert. Wenn dies weggelassen wird, versucht das Tool, einen Wert aus dem RCS-Revision-Tag zu erstellen (sofern verfügbar).
Hinweis Das soeben beschriebene Markup kann innerhalb der Klassen-, Kategorie- oder Protokolldokumentation verwendet werden. Wenn ja, wird es extrahiert und als Kapitel der Klasse in den Rest der Dokumentation für die Klasse eingebunden. Der Rest der Klassendokumentation wird normalerweise am Ende des Kapitels eingefügt, kann aber stattdessen anstelle des Pseudoelements
In Kommentaren, die zur Bereitstellung von Text für eine Methodenbeschreibung verwendet werden, wird das folgende Markup aus dem Text entfernt und speziell behandelt:
Die Methode wird als designierter Initialisierer für die Klasse markiert.
Die Methode wird als eine Methode markiert, die von Unterklassen überschrieben werden muss (z. B. eine abstrakte Methode).
Die Methode ist als eine Methode gekennzeichnet, die von Unterklassen NICHT überschrieben werden sollte.
Das Markup wird aus der Beschreibung entfernt und in der GSDoc-Ausgabe danach platziert, sodass die Methode als den angegebenen Standards entsprechend (oder nicht konform) beschrieben wird.
Im Allgemeinen wird der Text in Kommentaren neu formatiert, um ihn zu standardisieren und schön einzurücken. Die Neuformatierung wird nicht für Text innerhalb eines
Bestimmte bekannte Konstanten wie YES, NO und nil sind im ... -Markup eingeschlossen.
Die Namen von Methodenargumenten in Methodenbeschreibungen werden in das Markup ... eingeschlossen.
Methodennamen (die mit einem Plus- oder Minuszeichen beginnen) werden im
Methodenspezifizierer einschließlich Klassennamen (die mit eckigen Klammern beginnen und enden) werden in das Markup
Andere Funktionsnamen (die mit „()“ enden) als „main()“ werden in das Markup
Das Tool akzeptiert bestimmte Benutzerstandards (die natürlich als Befehlszeilenargumente bereitgestellt werden können, indem man „-“ vor dem Standardnamen voranstellt und den Wert danach angibt, wie in -Clean YES):
Wenn dieser boolesche Wert auf JA gesetzt ist, dann generiert das Tool keine Dokumentation, sondern alle im Projekt generierten GSDoc-Dateien und alle daraus generierten HTML-Dateien (sowie alle, die aus explizit aufgeführten GSDoc-Dateien generiert würden) und Entfernt schließlich die Projektindexdatei. Die einzige Ausnahme hiervon besteht darin, dass GSDoc-Vorlagendateien (d. h. diejenigen, die mit den Argumenten „-ConstantsTemplate ...“, „-FunctionsTemplate ...“ usw. angegeben werden) nicht gelöscht werden, es sei denn, das CleanTemplates-Flag ist gesetzt.
Dieses Flag gibt an, ob GSDoc-Vorlagendateien zusammen mit anderen Dateien entfernt werden sollen, wenn die Option „Clean“ angegeben ist. Standardmäßig werden sie nicht entfernt ... da diese Vorlagen möglicherweise manuell erstellt wurden und lediglich Daten eingefügt wurden.
Geben Sie den Namen eines Vorlagendokuments an, in das Dokumentation zu Konstanten aus allen Dateien im Projekt eingefügt werden soll. Dies ist nützlich, wenn Konstanten im Quellcode über viele Dateien verteilt sind und Sie sie an einem Ort gruppieren müssen. Sie sind dafür verantwortlich, sicherzustellen, dass das grundlegende Vorlagendokument (in das die individuelle Konstantendokumentation eingefügt wird) alle anderen gewünschten Informationen enthält. Der Einfachheit halber generiert autogsdoc jedoch eine einfache Vorlage (die Sie dann bearbeiten können), wenn die Datei dies tut nicht existieren. Das Einfügen erfolgt unmittelbar vor dem back-Element (oder, falls dieses nicht vorhanden ist, unmittelbar vor dem Ende des body-Elements) in der Vorlage.
Geben Sie an, wo Header als gefunden dokumentiert werden sollen. Der tatsächliche in der Dokumentation erzeugte Name wird gebildet, indem die letzte Komponente des Header-Dateinamens an den Wert dieses Standardwerts angehängt wird. Wenn dieser Standardwert nicht angegeben ist, wird der vollständige Name der Header-Datei (wie in der Befehlszeile angegeben) mit vorangestelltem HeaderDirectory-Standardwert verwendet. Eine typische Verwendung hierfür könnte „-Declared Foundation“ sein, wenn Dokumentation für die GNUstep-Basisbibliothek erstellt wird. Dies würde dazu führen, dass in der Dokumentation angegeben wird, dass NSString in „Foundation/NSString.h“ deklariert ist.
Mit diesem Flag können Sie eine Dokumentation für alle Instanzvariablen erstellen. Normalerweise werden nur diejenigen dokumentiert, die ausdrücklich als „öffentlich“ oder „geschützt“ deklariert sind.
Mit diesem Flag können Sie die Dokumentation für Instanzvariablen vollständig deaktivieren. Normalerweise werden explizit deklarierte „öffentliche“ oder „geschützte“ Instanzvariablen dokumentiert.
Wenn dieses Flag gesetzt ist, weist es den HTML-Generator an, die Dokumentation der Instanzvariablen am Ende der Klasse statt am Anfang zu platzieren. Dies ist nützlich, wenn Sie viele geschützte Instanzvariablen verwenden, die für allgemeine Benutzer der Klasse nur von untergeordnetem Interesse sind.
Kann verwendet werden, um das Verzeichnis anzugeben, in dem die generierte Dokumentation abgelegt werden soll. Wenn dies nicht festgelegt ist, wird die Ausgabe im aktuellen Verzeichnis abgelegt. Dieses Verzeichnis wird auch als letzter Ausweg zum Auffinden von Quelldateien (keine Header) verwendet und, was noch wichtiger ist, es wird als erster und einziger Ausweg zum Auffinden aller .gsdoc-Dateien verwendet, die an übergeben werden Befehlszeile. Alle für diese Dateien angegebenen Pfadinformationen werden entfernt und sie werden im „DocumentationDirectory“ gesucht (auch wenn sie möglicherweise nicht automatisch generiert wurden).
Gibt den Namen einer Datei an, die eine Liste von Dateinamen im Eigenschaftenlistenarray-Format (name1,name2,...) enthält. Wenn dies vorhanden ist, werden Dateinamen in der Programmargumentliste ignoriert und die Namen in dieser Datei werden als Liste der zu verarbeitenden Namen verwendet.
Geben Sie den Namen eines Vorlagendokuments an, in das Dokumentation zu Funktionen aus allen Dateien im Projekt eingefügt werden soll. Dies ist nützlich, wenn der Funktionsquellcode auf viele Dateien verteilt ist und Sie ihn an einem Ort gruppieren müssen. Sie sind dafür verantwortlich, sicherzustellen, dass das grundlegende Vorlagendokument (in das die individuelle Funktionsdokumentation eingefügt wird) alle anderen gewünschten Informationen enthält. Der Einfachheit halber generiert autogsdoc jedoch eine einfache Vorlage (die Sie dann bearbeiten können), wenn die Datei dies tut nicht existieren. Das Einfügen erfolgt unmittelbar vor dem back-Element (oder, falls dieses nicht vorhanden ist, unmittelbar vor dem Ende des body-Elements) in der Vorlage.
Kann verwendet werden, um anzugeben, ob eine HTML-Ausgabe generiert werden soll. Der Standardwert ist JA.
Kann verwendet werden, um das Verzeichnis anzugeben, das nach Header-Dateien durchsucht werden soll. Bei Angabe wird dieser Wert den relativen Header-Namen vorangestellt, andernfalls werden die relativen Header-Namen relativ zum aktuellen Verzeichnis interpretiert. Als absolute Pfade angegebene Header-Dateien werden von dieser Standardeinstellung nicht beeinflusst.
Ein boolescher Wert, der verwendet werden kann, um anzugeben, dass das Programm Dateiänderungszeiten ignorieren und Dateien trotzdem neu generieren soll. Wird zur Verwendung in Verbindung mit dem „make“-System bereitgestellt, von dem erwartet wird, dass es die Abhängigkeitsprüfung selbst verwaltet.
Dieser Wert wird verwendet, um die automatische Einbeziehung lokaler externer Projekte in das Indexierungssystem zur Generierung von Querverweisen in der endgültigen Dokumentausgabe zu steuern. Wenn auf „None“ gesetzt, werden keine lokalen Projektverweise erstellt. Andernfalls wird das „Lokale“ GNUstep-Dokumentationsverzeichnis rekursiv nach Dateien mit der Erweiterung „.igsdoc“ durchsucht und die Indizierungsinformationen dieser Dateien werden verwendet. Der Wert dieser Zeichenfolge wird auch zum Generieren der Dateinamen im Querverweis verwendet. Wenn es sich um eine leere Zeichenfolge handelt, wird davon ausgegangen, dass der zu verwendende Pfad eine Datei im selben Verzeichnis ist, in dem die igsdoc-Datei gefunden wurde, andernfalls ist dies der Fall Wird als Präfix für den Namen im Index verwendet. NB. Lokale Projekte mit demselben Namen wie das aktuell dokumentierte Projekt werden von diesem Mechanismus nicht einbezogen. Wenn Sie solche Projekte einbinden möchten, müssen Sie dies explizit über -Projects ... tun
Geben Sie den Namen eines Vorlagendokuments an, in das Dokumentation zu Makros aus allen Dateien im Projekt eingefügt werden soll. Dies ist nützlich, wenn der Makrocode über viele Dateien verteilt ist und Sie ihn an einem Ort gruppieren müssen. Sie sind dafür verantwortlich, sicherzustellen, dass das grundlegende Vorlagendokument (in das die individuelle Makrodokumentation eingefügt wird) alle anderen gewünschten Informationen enthält. Der Einfachheit halber generiert autogsdoc jedoch eine einfache Vorlage (die Sie dann bearbeiten können), wenn die Datei dies tut nicht existieren. Das Einfügen erfolgt unmittelbar vor dem back-Element (oder, falls dieses nicht vorhanden ist, unmittelbar vor dem Ende des body-Elements) in der Vorlage.
Ein Dateiname, der zur Ausgabe von Abhängigkeitsinformationen für make verwendet wird. Dies erfolgt in Form einer Auflistung aller für das Projekt bekannten Header- und Quelldateien als Abhängigkeiten des Projektnamens (siehe „Projekt“).
Kann verwendet werden, um den Namen dieses Projekts anzugeben ... bestimmt den Namen der Indexreferenzdatei, die als Teil der Dokumentation erstellt wird, um Informationen bereitzustellen, die es anderen Projekten ermöglichen, auf Elemente in diesem Projekt zu verweisen.
Dieser Wert kann als Wörterbuch bereitgestellt werden, das die Pfade zu den von externen Projekten verwendeten igsdoc-Index-/Referenzdateien sowie Werte enthält, die zum Zuordnen der in den Indizes gefundenen Dateinamen verwendet werden sollen. Wenn beispielsweise eine Projektindexdatei (igsdoc) besagt, dass die Klasse „Foo“ in der Datei „Foo“ gefunden wird und der diesem Projektindex zugeordnete Pfad „/usr/share/doc/proj“ lautet, wird HTML generiert Die Ausgabe kann auf die Klasse als in „/usr/share/doc/prj/Foo.html“ befindlich verweisen. Beachten Sie, dass ein Wörterbuch in der Befehlszeile angegeben werden kann, indem Sie das Standard-PropertyList-Format (nicht das XML-Format von OS X) verwenden, Semikolons als Zeilentrennzeichen verwenden und es in einfache Anführungszeichen setzen.
Ein boolescher Wert, der verwendet werden kann, um anzugeben, dass das Programm protokollieren soll, welche Dateien aufgrund ihrer Abhängigkeiten von anderen Dateien neu generiert werden.
Ein boolescher Wert, der angibt, ob das Programm Informationen zur Standardkonformität in die Dokumentation einfügen soll. Dies sollte nur verwendet werden, wenn die GNUstep-Bibliotheken und -Tools selbst dokumentiert werden, da davon ausgegangen wird, dass der dokumentierte Code Teil von GNUstep ist und möglicherweise dem OpenStep-Standard entspricht oder MacOS-X-kompatible Methoden implementiert.
Dieser Wert wird verwendet, um die automatische Einbeziehung systemexterner Projekte in das Indexierungssystem zur Generierung von Querverweisen in der endgültigen Dokumentausgabe zu steuern. Wenn auf „None“ gesetzt, werden keine Systemprojektverweise erstellt. Andernfalls wird das GNUstep-Dokumentationsverzeichnis „System“ rekursiv nach Dateien mit der Erweiterung „.igsdoc“ durchsucht und die Indizierungsinformationen dieser Dateien werden verwendet. Der Wert dieser Zeichenfolge wird auch zum Generieren der Dateinamen im Querverweis verwendet. Wenn es sich um eine leere Zeichenfolge handelt, wird davon ausgegangen, dass der zu verwendende Pfad eine Datei im selben Verzeichnis ist, in dem die igsdoc-Datei gefunden wurde, andernfalls ist dies der Fall Wird als Präfix für den Namen im Index verwendet. NB. Systemprojekte mit demselben Namen wie das aktuell dokumentierte Projekt werden von diesem Mechanismus nicht einbezogen. Wenn Sie solche Projekte einbinden möchten, müssen Sie dies explizit über -Projects ... tun
Geben Sie den Namen eines Vorlagendokuments an, in das Dokumentation zu Typedefs aus allen Dateien im Projekt eingefügt werden soll. Dies ist nützlich, wenn der Typedef-Quellcode über viele Dateien verteilt ist und Sie ihn an einem Ort gruppieren müssen. Sie sind dafür verantwortlich, sicherzustellen, dass das grundlegende Vorlagendokument (in das die individuelle Typedef-Dokumentation eingefügt wird) alle anderen gewünschten Informationen enthält. Der Einfachheit halber generiert autogsdoc jedoch eine einfache Vorlage (die Sie dann bearbeiten können), wenn die Datei dies tut nicht existieren. Das Einfügen erfolgt unmittelbar vor dem back-Element (oder, falls dieses nicht vorhanden ist, unmittelbar vor dem Ende des body-Elements) in der Vorlage.
Eine Zeichenfolge, die zur Bereitstellung des Namens verwendet wird, der im „Up“-Link von generierten GSDoc-Dokumenten verwendet werden soll. Dies sollte normalerweise der Name einer Datei sein, die einen Index des Inhalts eines Projekts enthält. Wenn dieser fehlt oder auf eine leere Zeichenfolge gesetzt ist, wird in den Dokumenten kein „Up“-Link bereitgestellt.
Geben Sie den Namen eines Vorlagendokuments an, in das Dokumentation zu Variablen aus allen Dateien im Projekt eingefügt werden soll. Dies ist nützlich, wenn variabler Quellcode über viele Dateien verteilt ist und Sie ihn an einem Ort gruppieren müssen. Sie sind dafür verantwortlich, sicherzustellen, dass das grundlegende Vorlagendokument (in das die individuelle Variablendokumentation eingefügt wird) alle anderen gewünschten Informationen enthält. Der Einfachheit halber generiert autogsdoc jedoch eine einfache Vorlage (die Sie dann bearbeiten können), wenn die Datei dies tut nicht existieren. Das Einfügen erfolgt unmittelbar vor dem back-Element (oder, falls dieses nicht vorhanden ist, unmittelbar vor dem Ende des body-Elements) in der Vorlage.
Ein boolescher Wert, der angibt, ob eine ausführliche Debug-/Warnungsausgabe erzeugt werden soll.
Ein boolescher Wert, der angibt, ob eine Standardwarnungsausgabe (z. B. ein Bericht über undokumentierte Methoden) erstellt werden soll.
Dieser Wert ist ein Wörterbuch, das verwendet wird, um in den Quelldateien gefundene Bezeichner/Schlüsselwörter anderen Wörtern zuzuordnen. Im Allgemeinen müssen Sie dies nicht verwenden, aber manchmal ist es hilfreich, um zu vermeiden, dass der Parser durch die Verwendung von C-Präprozessormakros verwirrt wird. Sie können das Makro effektiv so umdefinieren, dass es weniger verwirrend ist. Der Wert, dem Sie den Bezeichner zuordnen, muss einer von Folgendem sein: Ein anderer Bezeichner, Eine leere Zeichenfolge – der Wert wird ignoriert, Zwei Schrägstriche ('//') – Der Rest der Zeile wird ignoriert. Beachten Sie, dass ein Wörterbuch in der Befehlszeile angegeben werden kann, indem Sie das Standard-PropertyList-Format (nicht das XML-Format von OS X) verwenden, Semikolons als Zeilentrennzeichen verwenden und es in einfache Anführungszeichen setzen.
Die Standardeinstellung „Nach oben“ wird verwendet, um den Namen eines Dokuments anzugeben, das als „Nach oben“-Link für alle anderen verwendeten Dokumente verwendet werden soll. Dieser Name darf keinen Pfad oder eine Erweiterung enthalten. Im Allgemeinen sollte das Dokument, auf das sich dieser Standard bezieht, ein handbearbeitetes GSDoc-Dokument sein, das über einen Abschnitt back mit einem Projektindex verfügen sollte. z.B.
<?xml version="1.0"?>
<!DOCTYPE gsdoc PUBLIC "-//GNUstep//DTD gsdoc 1.0.3//EN"
"http://www.gnustep.org/gsdoc-1_0_3.xml">
<gsdoc base="index">
<head>
<title>My project reference</title>
<author name="my name"></author>
</head>
<body>
<chapter>
<heading>My project reference</heading>
</chapter>
<back>
<index scope="project" type="title" />
</back>
</body>
</gsdoc> Source: .h, .m, .c
GSDoc: .gsdoc
Index: .igsdoc
HTML: .htmlMehrere GSDoc-Elemente werden noch nicht richtig in HTML gerendert. Dies sind:
Fehlermeldungen und Warnungen können aus jeder Phase der Pipeline stammen: Steuerung auf oberster Ebene, Quellanalyse, GSDoc-Analyse und Indizierung.
gsdoc(7), GNUstep(7)
Autogsdoc kombinierte die Fähigkeiten zweier früherer Tools, „autodoc“ und „gsdoc“, die jeweils die Quell->GSDoc- und GSDoc->HTML-Übersetzungen durchführten. Diese früheren Tools und das GSDoc-Format wurden für GNUstep basierend auf der früheren GDML-SGML-Sprache entwickelt.
Diese Handbuchseite erschien erstmals in gnustep-base 1.9.2 (März 2004).
autogsdoc wurde von Richard Frith-Macdonald
Diese Handbuchseite wurde von Adrian Robert