starting.doc

doxygen(一个自动从源代码生成文档的工具)的源代码

/******************************************************************************
 *
 * $Id: starting.doc,v 1.15 2001/03/19 19:27:39 root Exp $
 *
 * Copyright (C) 1997-2001 by Dimitri van Heesch.
 *
 * Permission to use, copy, modify, and distribute this software and its
 * documentation under the terms of the GNU General Public License is hereby 
 * granted. No representations are made about the suitability of this software 
 * for any purpose. It is provided "as is" without express or implied warranty.
 * See the GNU General Public License for more details.
 *
 * Documents produced by Doxygen are derivative works derived from the
 * input used in their production; they are not affected by this license.
 *
 */
/*! \page starting Getting started

The executable \c doxygen is the main program that parses the sources and 
generates the documentation. See section \ref doxygen_usage for more
detailed usage information.

The executable \c doxytag is only needed if you want to generate references 
to external documentation (i.e. documentation that was generated by doxygen) 
for which you do not have the sources or to create a search index for 
the search engine. See section \ref doxytag_usage for more detailed usage 
information.

The executable \c doxysearch is only needed if you want to use the search 
engine. See section \ref doxysearch_usage for more detailed usage information.

Optionally, the executable \c doxywizard is a GUI front-end for editing 
the configuration files that are used by doxygen.

\subsection step1 Step 1: Creating a configuration file

Doxygen uses a configuration file to determine all of its settings.
Each project should get its own configuration file. A project can consist
of a single source file, but can also be an entire source tree that is 
recursively scanned.

To simplify the creation of a configuration file, doxygen can create a 
template configuration file for you. To do this call \c doxygen with the \c -g 
option:

\verbatim
doxygen -g <config-file>
\endverbatim
where \<config-file\> is the name of the configuration file. If you omit
the file name, a file named \c Doxyfile will be created. If a file with the
name \<config-file\> already exists, doxygen will rename it to 
\<config-file\>.bak before generating the configuration template.
If you use <code>-</code> (i.e. the minus sign) as the file name then 
doxygen will try to read the configuration file from standard 
input (<code>stdin</code>).

The configuration file has a format that is similar to that of a (simple) 
Makefile. It contains of a number of assignments (tags) of the form:

<tt>TAGNAME = VALUE</tt> or <br>
<tt>TAGNAME = VALUE1 VALUE2 ... </tt><br>

You can probably leave the values of most tags in a generated template 
configuration file to their default value. 

The \ref cfg_input "INPUT" tag is the only tag for which you are required to 
provide a value. See section \ref config for more details about the 
configuration file. For a small project consisting of a few C and/or C++ source 
and header files, you can add the names of the files after the 
\ref cfg_input "INPUT" tag. 

If you have a larger project consisting of a source directory or tree this may 
become tiresome. In this case you should put the root directory or 
directories after the \ref cfg_input "INPUT" tag, and add one or more file 
patterns to the \ref cfg_file_patterns "FILE_PATTERNS" tag 
(for instance <code>*.cpp *.h</code>). Only files that match one of the 
patterns will be parsed (if the patterns are omitted all files will be parsed).
For recursive parsing of a source tree you must set 
the \ref cfg_recursive "RECURSIVE" tag to \c YES. To further fine-tune the 
list of files that is parsed the \ref cfg_exclude "EXCLUDE" and 
\ref cfg_exclude_patterns "EXCLUDE_PATTERNS" tags can be used.

If you start using doxygen for an existing project (thus without any 
documentation that doxygen is aware of), you can still get an idea of
what the documented result would be. To do so, you must set 
the \ref cfg_extract_all "EXTRACT_ALL" tag in the configuration file 
to \c YES. Then, doxygen will pretend everything in your sources is documented. 
Please note that warnings of undocumented members will not be generated as 
long as \ref cfg_extract_all "EXTRACT_ALL" is set to \c YES.

To analyse an existing piece of software it is useful to cross-reference 
a (documented) entity with its definition in the source files. Doxygen will
generate such cross-references if you set 
the \ref cfg_source_browser "SOURCE_BROWSER" tag to \c YES.  
It can also include the sources directly into the documentation by setting
\ref cfg_inline_sources "INLINE_SOURCES" to \c YES (this can be handly for 
code reviews for instance).

\subsection step2 Step 2: Running doxygen

To generate the documentation you can now enter:
\verbatim
doxygen <config-file>
\endverbatim

Doxygen will create a \c html, \c rtf, \c latex and/or \c man directory inside 
the output directory. 
As the names suggest these directories contain the
generated documentation in HTML, RTF, \f$\mbox{\LaTeX}\f$ and Unix-Man page
format.

The default output directory is the directory in which \c doxygen
is started. The directory to which the output is written can be changed 
using the \ref cfg_output_directory "OUTPUT_DIRECTORY", 
\ref cfg_html_output "HTML_OUTPUT", \ref cfg_rtf_output "RTF_OUTPUT",
\ref cfg_latex_output "LATEX_OUTPUT", and \ref cfg_man_output "MAN_OUTPUT" 
tags of the configuration file. If the output directory does not exist, 
\c doxygen will try to create it for you.

\addindex browser
The generated HTML documentation can be viewed by pointing a HTML browser
to the \c index.html file in the \c html directory. For the best results
a browser that supports cascading style sheets (CSS) should be used
(I'm currently using Netscape 4.61 to test the generated output).
\addindex LaTeX

The generated \f$\mbox{\LaTeX}\f$ documentation must first be compiled by 
a \f$\mbox{\LaTeX}\f$ compiler (I use teTeX distribution version 0.9
that contains \f$\mbox{\TeX}\f$ version 3.14159). To simplify the process 
of compiling the generated
documentation, \c doxygen writes a \c Makefile into the \c latex directory. 
By typing \c make in the \c latex directory the dvi file \c refman.dvi
will be generated (provided that you have a make tool called 
<code>make</code> of course). This file can then be viewed using \c xdvi or 
converted into a PostScript file \c refman.ps by 
typing <code>make ps</code> (this requires <code>dvips</code>).  
To put 2 pages on one physical page use <code>make ps_2on1</code> instead.
The resulting PostScript file can be send to a PostScript
printer. If you do not have a PostScript printer, you can try to use 
ghostscript to convert PostScript into something your printer understands.
Conversion to PDF is also possible if you have installed the ghostscript
interpreter; just type <code>make pdf</code> (or <code>make pdf_2on1</code>). 
To get the best results for PDF output you should set 
the \ref cfg_pdf_hyperlinks "PDF_HYPERLINKS" tag to \c YES.

The generated man pages can be viewed using the \c man program. You do need
to make sure the man directory is in the man path (see the \c MANPATH
environment variable). Note that there are some limitations to the 
capabilities of the man page format, so some information 
(like class diagrams, cross references and formulas) will be lost.

\subsection step3 Step 3: Documenting the sources

Although documenting the source is presented as step 3, in a new project 
this should of course be step 1. Here I assume
you already have some code and you want doxygen to generate a nice document 
describing the API and maybe the internals as well.

If the \ref cfg_extract_all "EXTRACT_ALL" option is set to \c NO in the 
configuration file (the default), then doxygen will only generate 
documentation for \e documented members, files, classes and namespaces. So 
how do you document these? For members, classes and namespaces there are 
basically two options:
<ol>
<li>Place a \e special documentation block in front of the declaration or
    definition of the member, class or namespace. For file, class and namespace
    members it is also allowed to place the documention directly after the 
    member. See section \ref specialblock to learn more about special 
    documentation blocks.
<li>Place a special documentation block somewhere else (another file or 
    another location) \e and put a <em>structural command</em> in the 
    documentation block. A structural command links a documentation block 
    to a certain entity that can be documented (e.g. a member, class, 
    namespace or file). See section \ref structuralcommands to learn more 
    about structural commands.
</ol>
Files can only be documented using the second option.
The text inside a special documentation block is parsed
before it is written to the HTML and/or \f$\mbox{\LaTeX}\f$ output files.

\addindex parsing
During parsing the following steps take place:
<ul>
<li> The special commands inside the documentation are executed. See
     section \ref commands for an overview of all commands.
<li> If a line starts with some whitespace followed by one or more asterixes 
     (<tt>*</tt>) and then optionally more whitespace, 
     then all whitespace and asterixes are removed.
<li> All resulting blank lines are treated as a paragraph separators.
     This saves you from placing new-paragraph commands yourself 
     in order to make the generated documentation readable.
<li> Links are created for words corresponding to documented classes. 
<li> Links to members are created when certain patterns are found in the
     text. See section \ref autolink
     for more information on how the automatic link generation works.
<li> HTML tags that are in the documentation are interpreted and converted 
     to \f$\mbox{\LaTeX}\f$ equivalents for the \f$\mbox{\LaTeX}\f$ output. 
     See section \ref htmlcmds for an overview of all supported HTML tags.
</ul>

\htmlonly
Go to the <a href="docblocks.html">next</a> section or return to the
 <a href="index.html">index</a>.
\endhtmlonly

*/