Server : Apache/2.4.41 (Ubuntu) System : Linux absol.cf 5.4.0-198-generic #218-Ubuntu SMP Fri Sep 27 20:18:53 UTC 2024 x86_64 User : www-data ( 33) PHP Version : 7.4.33 Disable Function : pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare, Directory : /usr/share/doc/gnustep-base-doc/Tools/Reference/
Upload File :
Current File : //usr/share/doc/gnustep-base-doc/Tools/Reference/autogsdoc.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>
Autogsdoc... a tool to make documentation from source
code
</title>
</head>
<body>
<font face="serif">
<a href="BaseTools.html">Up</a>
<br />
<h1><a name="title$autogsdoc">
Autogsdoc... a tool to make documentation from source
code
</a></h1>
<h3>Authors</h3>
<dl>
<dt>Richard Frith-Macdonald (<a href="mailto:richard@brainstorm.co.uk"><code>richard@brainstorm.co.uk</code></a>)</dt>
<dd>
</dd>
</dl>
<p><b>Copyright:</b> (C) 2001-2016 Free Software Foundation, Inc.</p>
<div>
<hr width="50%" align="left" />
<h3>Contents -</h3>
<ol>
<li>
<a href="#001000000000">The autogsdoc tool</a>
</li>
<li>
<a href="#001001000000">Overview</a>
</li>
<li>
<a href="#001002000000">Source Code Markup</a>
</li>
<li>
<a href="#001003000000">Extra markup</a>
</li>
<li>
<a href="#001004000000">Method markup</a>
</li>
<li>
<a href="#001005000000">Automated markup</a>
</li>
<li>
<a href="#001006000000">Arguments and Defaults</a>
</li>
<li>
<a href="#001007000000">Inter-document linkage</a>
</li>
<li>
<a href="#001008000000">Implementation Notes</a>
</li>
</ol>
<hr width="50%" align="left" />
</div>
<h1><a name="001000000000">The autogsdoc tool</a></h1>
<h2><a name="001001000000">Overview</a></h2>
<p>
The autogsdoc tool is a command-line utility that helps
developers produce reference documentation for
GNUstep APIs. It also enables developers to write and
maintain other documentation in XML and have it
converted to HTML. In detail, autogsdoc will:
</p>
<ul>
<li>
Extract special comments describing the public
interfaces of classes, categories, protocols,
functions, and macros from Objective C source
code (header files and optionally source files) into
GSDoc XML files. (Note that since C is a subset of
Objective C, this tool can operate to document
functions and other C structures in plain C
source.)
</li>
<li>
Convert GSDoc XML files, whether generated from
source code or written manually by developers, into
HTML.
</li>
<li>
Construct indices based on GSDoc XML file sets,
and convert those to HTML as well.
</li>
</ul>
<p>
synopsis: <code>autogsdoc (options) (files)</code>
<br />     (options) described
below <br />     (files)
<code>.h</code>, <code>.m</code>, <code>.gsdoc</code>,
and/or <code>.html</code> files, in any order.
</p>
<p>
The most common usage this is to run the command with one
or more header file names as arguments... the tool will
automatically parse corresponding source files
in the same directory as the headers (or the current
directory, or the directory specified using the
DocumentationDirectory default), and
produce GSDoc and HTML files as output. For best
results this mode should be run from the directory
containing the source files.
</p>
<p>
GSDoc files may also be given directly in addition or
by themselves, and will be converted to HTML. See the
<a href="gsdoc.html">
GSDoc reference
</a>
for information on the GSDoc format.
</p>
<p>
Finally, HTML files may be given on the command
line. Cross-references to other parts of code
documentation found within them will be
rewritten based on what is found in the project
currently.
</p>
<h2><a name="001002000000">Source Code Markup</a></h2>
<p>
The source code parser will automatically produce GSDoc
documents listing the methods in the classes found
in the source files, and it will include text from
specially formatted comments from the source files.
</p>
<p>
Any comment beginning with slash and <em>two</em>
asterisks rather than the common slash and single
asterisk, is taken to be GSDoc markup, to be use as
the description of the class or method following it. This
comment text is reformatted and then inserted into
the output. <br /> Where multiple comments are associated
with the same item, they are joined together with a line
break (<br />) between each if necessary. <br />
Within a comment the special markup <ignore> and
</ignore> may be used to tell autogsdoc
to completely ignore the sourcecode between these two
pieces of markup (ie. the parser will skip from the
point just before it is told to start ignoring, to just
after the point where it is told to stop (or end of
file if that occurs first).
</p>
<p>
The tool can easily be used to document programs as well
as libraries, simply by giving it the name of the source
file containing the main() function of the program - it
takes the special comments from that function and
handles them specially, inserting them as a section
at the end of the first chapter of the document (it
creates the first chapter if necessary).
</p>
<p>
<strong>Options</strong> are described in the
section <em>Arguments and Defaults</em> below.
</p>
<h2><a name="001003000000">Extra markup</a></h2>
<p>
There are some cases where special extra processing is
performed, predominantly in the first comment
found in the source file, from which various chunks of
GSDoc markup may be extracted and placed into
appropriate locations in the output document -
</p>
<ul>
<li>
<strong>AutogsdocSource</strong> :  In any
line where <code>AutogsdocSource</code> :  is
found, the remainder of the line is taken as a
source file name to be used instead of making the
assumption that each .h file processed uses
a  .m file of the same name. You may supply multiple
<code>AutogsdocSource</code> :  lines where a
header file declares items which are defined in
multiple source files. <br /> If a file name is
absolute, it is used just as supplied. <br /> If
on the other hand, it is a relative path, the software
looks for the source file first relative to the
location of the header file, and if not found
there, relative to the current directory in which
autogsdoc is running, and finally relative to the
directory specified by the
<code>DocumentationDirectory</code> default.
</li>
<li>
<strong><abstract></strong> An abstract of
the content of the document... placed in the head of
the GSDoc output.
</li>
<li>
<strong><author></strong> A description of
the author of the code - may be repeated to handle the
case where a document has multiple authors. Placed in
the head of the GSDoc output. <br /> As an aid to
readability of the source, some special
additional processing is performed related to
the document author - <br /> Any line of the form '
<code>Author</code> : name <email-address>',
or ' <code>By</code> : name <email-address>', or '
<code>Author</code> : name' or ' <code>By</code> :
name' will be recognised and converted to an
<em>author</em> element, possibly containing an
<em>email</em> element.
</li>
<li>
<strong><back></strong> Placed in the GSDoc
output just before the end of the body of the
document - intended to be used for appendices,
index etc..
</li>
<li>
<strong><chapter></strong> Placed
immediately before any generated class
documentation... intended to be used to
provide overall description of how the code being
documented works. <br /> Any documentation for
the main() function of a program is inserted as a
section at the end of this chapter.
</li>
<li>
<strong><copy></strong> Copyright of the
content of the document... placed in the head of
the GSDoc output. <br /> As an aid to readability of
the source, some special additional processing is
performed - <br /> Any line of the form
'Copyright (C) text' will be recognised and
converted to a <em>copy</em> element.
</li>
<li>
<strong><date></strong> Date of the revision
of the document... placed in the head of the GSDoc
output. If this is omitted the tool will try to
construct a value from the RCS Date tag (if
available).
</li>
<li>
<strong><front></strong> Inserted into the
document at the start of the body... intended to
provide for introduction or contents pages etc.
</li>
<li>
<strong><title></strong> Title of the
document... placed in the head of the GSDoc
output. If this is omitted the tool will generate a
(probably poor) title of its own - so you should
include this markup manually.
</li>
<li>
<strong><version></strong> Version
identifier of the document... placed in the head
of the GSDoc output. If this is omitted the tool will
try to construct a value from the RCS Revision tag (if
available).
</li>
</ul>
<p>
<strong>NB</strong> The markup just described may be
used within class, category, or protocol documentation
... if so, it is extracted and wrapped round the rest of
the documentation for the class as the class's chapter.
The rest of the class documentation is normally inserted
at the end of the chapter, but may instead be substituted
in in place of the <unit /> pseudo-element within
the <chapter> element.
</p>
<h2><a name="001004000000">Method markup</a></h2>
<p>
In comments being used to provide text for a method
description, the following markup is removed
from the text and handled specially -
</p>
<ul>
<li>
<strong><init /></strong> The method is
marked as being the designated initialiser for the
class.
</li>
<li>
<strong><override-subclass /></strong> The
method is marked as being one which subclasses must
override (e.g. an abstract method).
</li>
<li>
<strong><override-dummy /></strong> The
method is marked as being one which is a dummy
implementation intended for subclasses to
override, though not one they are forced to
implement.
</li>
<li>
<strong><override-never /></strong> The
method is marked as being one which subclasses
should <em>NOT</em> override.
</li>
</ul>
<h2><a name="001005000000">Automated markup</a></h2>
<p>
Generally, the text in comments is reformatted to
standardise and indent it nicely... the
reformatting is <em>not</em> performed on any
text inside an <example> element. <br /> When the
text is reformatted, it is broken into whitespace
separated 'words' which are then subjected to some
extra processing...
</p>
<ul>
<li>
Certain well known constants such as
<code>YES</code>, <code>NO</code>, and
<code>nil</code> are enclosed in <code>...
</code> markup.
</li>
<li>
The names of method arguments within method
descriptions are enclosed in <var>...
</var> markup.
</li>
<li>
Method names (beginning with a plus or minus) are
enclosed in <ref...>... </ref> markup.
<br /> e.g. "-init" (without the quotes) would be
wrapped in a GSDoc reference element to point to
the init method of the current class or, if only one
known class had an init method, it would refer to the
method of that class. <br /> Note the fact that the
method name must be surrounded by whitespace to be
recognized (though a comma, fullstop, or
semicolon at the end of the specifier will act
like whitespace).
</li>
<li>
Method specifiers including class names (beginning
and ending with square brackets) are enclosed in
<ref...>... </ref> markup.
<br /> e.g. <code>[</code> NSObject-init
<code>]</code>, will create a reference to the init
method of NSObject (either the class proper, or any
of its categories), while <br /> <code>[</code>
(NSCopying)-copyWithZone:
<code>]</code>, creates a reference to a method in
the NSCopying protocol. <br /> Note that no spaces must
appear between the square brackets in these
specifiers. <br /> Protocol names are enclosed
in round brackets rather than the customary angle
brackets, because GSDoc is an XML language, and
XML treats angle brackets specially.
</li>
<li>
<strong>Class</strong> names (and also protocol
and category names) enclosed in square brackets are
also cross referenced. <br /> Protocol names are
enclosed in round brackets rather than the
customary angle brackets, because GSDoc is an XML
language, and XML treats angle brackets
specially.
</li>
<li>
Function names (ending with '()') other than
'main()' are enclosed in <ref...>...
</ref> markup. <br /> e.g. "NSLogv()"
(without the quotes) would be wrapped in a GSDoc
reference element to point to the documentation
of the NSLog function. <br /> Note the fact that the
function name must be surrounded by whitespace
(though a comma, fullstop, or semicolon at the end
of the specifier will also act as a whitespace
terminator). <br />
</li>
</ul>
<h2><a name="001006000000">Arguments and Defaults</a></h2>
<p>
The tool accepts certain user defaults (which can of
course be supplied as command-line arguments by
prepending '-' before the default name and giving
the value afterwards, as in -
<code>Clean <code>YES</code></code>):
</p>
<ul>
<li>
<strong>Clean</strong> If this boolean value is
set to <code>YES</code>, then rather than generating
documentation, the tool removes all GSDoc
files generated in the project, and all html files
generated from them (as well as any which would
be generated from GSDoc files listed explicitly), and
finally removes the project index file. <br /> The
only exception to this is that template GSDoc files
(i.e. those specified using "-ConstantsTemplate...",
"-FunctionsTemplate..." arguments etc)
are not deleted unless the CleanTemplates flag is set.
</li>
<li>
<strong>CleanTemplates</strong> This flag
specifies whether template GSDoc files are to be
removed along with other files when the Clean
option is specified. The default is for them not to
be removed... since these templates may have been
produced manually and just had data inserted into
them.
</li>
<li>
<strong>ConstantsTemplate</strong> Specify the
name of a template document into which documentation
about constants should be inserted from all files in
the project. <br /> This is useful if constants in the
source code are scattered around many files, and you
need to group them into one place. <br /> You are
responsible for ensuring that the basic
template document (into which individual constant
documentation is inserted) contains all the
other information you want, but as a convenience
autogsdoc will generate a simple template (which
you may then edit) for you if the file does not exist.
<br /> Insertion takes place immediately before the
<em>back</em> element (or if that does not exist,
immediately before the end of the <em>body</em>
element) in the template.
</li>
<li>
<strong>Declared</strong> Specify where headers
are to be documented as being found. <br /> The actual
name produced in the documentation is formed by
appending the last component of the header file
name to the value of this default. <br /> If this
default is not specified, the full name of the
header file (as supplied on the command line), with
the HeaderDirectory default prepended, is used. <br />
A typical usage of this might be
<code>"-Declared Foundation"</code> when generating
documentation for the GNUstep base library.
This would result in the documentation saying that
NSString is declared in
<code>Foundation/NSString.h</code>
</li>
<li>
<strong>DocumentAllInstanceVariables</strong> This
flag permits you to generate documentation for all
instance variables. Normally, only those
explicitly declared 'public' or 'protected' will
be documented.
</li>
<li>
<strong>DocumentInstanceVariables</strong> This
flag permits you to turn off documentation for
instance variables completely. Normally,
explicitly declared 'public' or 'protected'
instance variables will be documented.
</li>
<li>
<strong>InstanceVariablesAtEnd</strong> This flag,
if set, directs the HTML generator to place instance
variable documentation at the end of the class,
instead of the beginning. This is useful if you use
a lot of protected instance variables which are only
going to be of secondary interest to general users of
the class.
</li>
<li>
<strong>DocumentationDirectory</strong> May be
used to specify the directory in which generated
documentation is to be placed. If this is not
set, output is placed in the current directory. This
directory is also used as a last resort to locate
source files (not headers), and more importantly, it
is used as the <em>first and only</em> resort to locate
any <code>.gsdoc</code> files that are passed in on the
command line. Any path information given for these
files is <em><strong>removed</strong></em> and they
are searched for in <code>DocumentationDirectory</code>
(even though they may not have been autogenerated).
</li>
<li>
<strong>Files</strong> Specifies the name of a
file containing a list of file names as a property
list array <em>(name1,name2,...)</em> format. If this
is present, filenames in the program argument list are
ignored and the names in this file are used as the
list of names to process.
</li>
<li>
<strong>FunctionsTemplate</strong> Specify the
name of a template document into which documentation
about functions should be inserted from all files in
the project. <br /> This is useful if function source
code is scattered around many files, and you need to
group it into one place. <br /> You are responsible
for ensuring that the basic template document (into
which individual function documentation is inserted)
contains all the other information you want, but
as a convenience autogsdoc will generate a simple
template (which you may then edit) for you if the
file does not exist. <br /> Insertion takes place
immediately before the <em>back</em> element
(or if that does not exist, immediately before the end
of the <em>body</em> element) in the template.
</li>
<li>
<strong>GenerateHtml</strong> May be used to
specify if HTML output is to be generated. Defaults
to <code>YES</code>.
</li>
<li>
<strong>HeaderDirectory</strong> May be used to
specify the directory to be searched for header
files. When supplied, this value is prepended to
relative header names, otherwise the relative
header names are interpreted relative to the current
directory. <br /> Header files specified as
absolute paths are not influenced by this default.
</li>
<li>
<strong>IgnoreDependencies</strong> A boolean
value which may be used to specify that the program
should ignore file modification times and regenerate
files anyway. Provided for use in conjunction with
the <code>make</code> system, which is expected to
manage dependency checking itself.
</li>
<li>
<strong>LocalProjects</strong> This value is used
to control the automatic inclusion of local external
projects into the indexing system for generation
of cross-references in final document output. <br /> If
set to 'None', then no local project references are
done, otherwise, the 'Local' GNUstep documentation
directory is recursively searched for files with
a <code>.igsdoc</code> extension, and the indexing
information from those files is used. <br />
The value of this string is also used to generate the
filenames in the cross reference... if it is an
empty string, the path to use is assumed to be a file
in the same directory where the igsdoc file was found,
otherwise it is used as a prefix to the name in
the index. <br /> NB. Local projects with the same name
as the project currently being documented will
<em>not</em> be included by this mechanism. If you
wish to include such projects, you must do so
explicitly using <em>"-Projects..."</em>
</li>
<li>
<strong>MacrosTemplate</strong> Specify the name
of a template document into which documentation about
macros should be inserted from all files in the
project. <br /> This is useful if macro code is
scattered around many files, and you need to
group it into one place. <br /> You are responsible
for ensuring that the basic template document (into
which individual macro documentation is inserted)
contains all the other information you want, but
as a convenience autogsdoc will generate a simple
template (which you may then edit) for you if the
file does not exist. <br /> Insertion takes place
immediately before the <em>back</em> element
(or if that does not exist, immediately before the end
of the <em>body</em> element) in the template.
</li>
<li>
<strong>MakeDependencies</strong> A filename to be
used to output dependency information for make. This
will take the form of listing all header and source
files known for the project as dependencies of the
project name (see <code>Project</code>).
</li>
<li>
<strong>Project</strong> Specifies the name of
this project... determines the name of the index
reference file produced as part of the
documentation to provide information enabling
other projects to cross-reference to items in this
project. If not set, 'Untitled' is used.
</li>
<li>
<strong>Projects</strong> This value may be
supplied as a dictionary containing the paths to
the igsdoc index/reference files used by external
projects, along with values to be used to map the
filenames found in the indexes. <br /> For
example, if a project index (igsdoc) file says
that the class <code>Foo</code> is found in the file
<code>Foo</code>, and the path associated with that
project index is <code>/usr/doc/proj</code>, Then
generated html output may reference the class as
being in <code>/usr/doc/prj/Foo.html</code>. Note
that a dictionary may be given on the command line by
using the standard PropertyList format (not the XML
format of OS X), using semicolons as
line-separators, and enclosing it in
single quotes.
</li>
<li>
<strong>ShowDependencies</strong> A boolean value
which may be used to specify that the program should
log which files are being regenerated because of their
dependencies on other files.
</li>
<li>
<strong>Standards</strong> A boolean value used to
specify whether the program should insert
information about standards complience into the
documentation. This should only be used when
documenting the GNUstep libraries and tools
themselves as it assumes that the code being
documented is part of GNUstep and possibly
complies with the OpenStep standard or implements
MacOS-X compatible methods.
</li>
<li>
<strong>SystemProjects</strong> This value is used
to control the automatic inclusion of system external
projects into the indexing system for generation
of cross-references in final document output. <br /> If
set to 'None', then no system project references are
done, otherwise, the 'System' GNUstep documentation
directory is recursively searched for files with
a <code>.igsdoc</code> extension, and the indexing
information from those files is used. <br />
The value of this string is also used to generate the
filenames in the cross reference... if it is an
empty string, the path to use is assumed to be a file
in the same directory where the igsdoc file was found,
otherwise it is used as a prefix to the name in
the index. <br /> NB. System projects with the same
name as the project currently being documented will
<em>not</em> be included by this mechanism. If you
wish to include such projects, you must do so
explicitly using <em>"-Projects..."</em>
</li>
<li>
<strong>TypedefsTemplate</strong> Specify the name
of a template document into which documentation about
typedefs should be inserted from all files in the
project. <br /> This is useful if typedef source
code is scattered around many files, and you need to
group it into one place. <br /> You are responsible
for ensuring that the basic template document (into
which individual typedef documentation is inserted)
contains all the other information you want, but
as a convenience autogsdoc will generate a simple
template (which you may then edit) for you if the
file does not exist. <br /> Insertion takes place
immediately before the <em>back</em> element
(or if that does not exist, immediately before the end
of the <em>body</em> element) in the template.
</li>
<li>
<strong>Up</strong> A string used to supply the
name to be used in the 'up' link from generated GSDoc
documents. This should normally be the name of a
file which contains an index of the contents of a
project. <br /> If this is missing or set to an
empty string, then no 'up' link will be provided in
the documents.
</li>
<li>
<strong>VariablesTemplate</strong> Specify the
name of a template document into which documentation
about variables should be inserted from all files in
the project. <br /> This is useful if variable source
code is scattered around many files, and you need to
group it into one place. <br /> You are responsible
for ensuring that the basic template document (into
which individual variable documentation is inserted)
contains all the other information you want, but
as a convenience autogsdoc will generate a simple
template (which you may then edit) for you if the
file does not exist. <br /> Insertion takes place
immediately before the <em>back</em> element
(or if that does not exist, immediately before the end
of the <em>body</em> element) in the template.
</li>
<li>
<strong>Verbose</strong> A boolean used to specify
whether you want verbose debug/warning output to be
produced.
</li>
<li>
<strong>Warn</strong> A boolean used to specify
whether you want standard warning output (e.g.
report of undocumented methods) produced.
</li>
<li>
<strong>WordMap</strong> This value is a
dictionary used to map identifiers/keywords
found in the source files to other words. Generally
you will not have to use this, but it is sometimes
helpful to avoid the parser being confused by the
use of C preprocessor macros. You can effectively
redefine the macro to something less confusing.
<br /> The value you map the identifier to must be
one of - <br /> Another identifier, <br /> An empty
string - the value is ignored, <br /> Two slashes
('//') - the rest of the line is ignored. <br />
Note that a dictionary may be given on the command
line by using the standard PropertyList format (not
the XML format of OS X), using semicolons as
line-separators, and enclosing it in
single quotes.
</li>
</ul>
<h2><a name="001007000000">Inter-document linkage</a></h2>
<p>
The 'Up' default is used to specify the name of a
document which should be used as the 'up' link for
any other documents used. <br /> This name must not
include a path or extension. <br /> Generally, the
document referred to by this default should be a
hand-edited GSDoc document which should have a
<em>back</em> section containing a project index. e.g.
</p>
<pre>
<?xml version="1.0"?>
<!DOCTYPE gsdoc PUBLIC "-//GNUstep//DTD gsdoc 1.0.4//EN"
"http://www.gnustep.org/gsdoc-1_0_4.dtd">
<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>
</pre>
<h2><a name="001008000000">Implementation Notes</a></h2>
<p>
The autogsdoc tool internally makes use of the following four
classes-
</p>
<dl>
<dt><a rel="gsdoc" href="AGSParser.html#class$AGSParser">AGSParser</a>
</dt>
<dd>
Parses source code comments to an internal
representation.
</dd>
<dt><a rel="gsdoc" href="AGSOutput.html#class$AGSOutput">AGSOutput</a>
</dt>
<dd>
Converts internal representation of source comments to
a gsdoc document.
</dd>
<dt><a rel="gsdoc" href="AGSIndex.html#class$AGSIndex">AGSIndex</a>
</dt>
<dd>
Internal representation of an igsdoc file,
representing indices of a project's files.
</dd>
<dt><a rel="gsdoc" href="AGSHtml.html#class$AGSHtml">AGSHtml</a>
</dt>
<dd>
Converts gsdoc XML to HTML, using AGSIndex instances.
</dd>
</dl>
<div>
<b>Title Index</b>
<ul>
<li><a rel="gsdoc" href="AGSHtml.html#title$AGSHtml">AGSHtml... a class to output html for a gsdoc file</a></li>
<li><a rel="gsdoc" href="AGSIndex.html#title$AGSIndex">AGSIndex... a class to create references for a gsdoc
file</a></li>
<li><a rel="gsdoc" href="AGSOutput.html#title$AGSOutput">AGSOutput... a class to output gsdoc source</a></li>
<li><a rel="gsdoc" href="AGSParser.html#title$AGSParser">AGSParser...a class to get documention info from ObjC
source</a></li>
<li><a rel="gsdoc" href="BaseTools.html#title$BaseTools">Base Tools</a></li>
<li><a rel="gsdoc" href="cvtenc.html#title$cvtenc">cvtenc documentation</a></li>
<li><a rel="gsdoc" href="defaults.html#title$defaults">defaults documentation</a></li>
<li><a rel="gsdoc" href="gdnc.html#title$gdnc">gdnc documentation</a></li>
<li><a rel="gsdoc" href="gdomap.html#title$gdomap">gdomap documentation</a></li>
<li><a rel="gsdoc" href="gsdoc.html#title$gsdoc">GNUstep Documentation XML markup language (GSDoc)</a></li>
<li><a rel="gsdoc" href="gspath.html#title$gspath">gspath documentation</a></li>
<li><a rel="gsdoc" href="pldes.html#title$pldes">pldes documentation</a></li>
<li><a rel="gsdoc" href="plmerge.html#title$plmerge">plmerge documentation</a></li>
<li><a rel="gsdoc" href="plparse.html#title$plparse">plparse documentation</a></li>
<li><a rel="gsdoc" href="plser.html#title$plser">plser documentation</a></li>
<li><a rel="gsdoc" href="sfparse.html#title$sfparse">sfparse documentation</a></li>
<li><a rel="gsdoc" href="xmlparse.html#title$xmlparse">xmlparse... a tool to parse xml documents</a></li>
</ul>
</div>
<br />
<a href="BaseTools.html">Up</a>
</font>
</body>
</html>
Server : Apache/2.4.41 (Ubuntu)