+ A class (inheriting from Builder) that
+ takes
+ parsed documents and performs an action on them. Normally, builders
+ translate the documents to an output format, but it is also possible to
+ use builders that e.g. check for broken links in the documentation, or
+ build coverage information.
+
+ See Builders for an + overview over Sphinx\u2019s built-in + builders. +
+
+ The directory containing conf.py. By default, this is the
+ same as
+ the source
+ directory, but can be set differently with the -c
+ command-line option.
+
+ A reStructuredText markup element that allows marking a block of content + with special meaning. Directives are supplied not only by docutils, but + Sphinx and custom extensions can add their own. The basic directive + syntax looks like this: +
+.. directivename:: argument ...
+ :option: value
+
+ Content of the directive.
+
+ + See Directives for more information. +
+
+ Since reST source files can have different extensions (some people like
+ .txt, some like .rst \u2013 the extension can be
+ configured with
+ source_suffix)
+ and different OSes have different path
+ separators, Sphinx abstracts them: document names are always
+ relative to the source directory, the extension is stripped, and
+ path separators are converted to slashes. All values, parameters and such
+ referring to \u201cdocuments\u201d expect such document names.
+
+ Examples for document names are index, library/zipfile, or
+ reference/datamodel/types. Note that
+ there is no leading or trailing
+ slash.
+
+ A domain is a collection of markup (reStructuredText directives
+ and roles) to
+ describe and link to objects belonging
+ together, e.g. elements of a programming language. Directive and role
+ names in a domain have names like domain:name, e.g. py:function.
+
+ Having domains means that there are no naming problems when one set of + documentation wants to refer to e.g. C++ and Python classes. It also + means that extensions that support the documentation of whole new + languages are much easier to write. +
++ For more information, refer to Domains. +
++ A structure where information about all documents under the root is saved, + and used for cross-referencing. The environment is pickled after the + parsing stage, so that successive runs only need to read and parse new and + changed documents. +
++ A custom role, directive or + other aspect of Sphinx that + allows users to modify any aspect of the build process within Sphinx. +
++ For more information, refer to Extensions. +
+
+ The document that contains the root toctree directive.
+
+ The basic building block of Sphinx documentation. Every \u201cobject
+ directive\u201d (e.g. function or object) creates
+ such a
+ block; and most objects can be cross-referenced to.
+
+ The feature which is warned will be removed in Sphinx-XXX version. + It usually caused from Sphinx extensions which is using deprecated. + See also Deprecation + Warnings. +
+
+ A reStructuredText markup element that allows marking a piece of text.
+ Like directives, roles are extensible. The basic syntax looks like this:
+ :rolename:`content`. See Inline markup for details.
+
+ The directory which, including its subdirectories, contains all source + files for one Sphinx project. +
++ An easy-to-read, what-you-see-is-what-you-get plaintext markup syntax and + parser system. +
++ The feature which is warned will be removed in Sphinx-XXX version. + It usually caused from Sphinx extensions which is using deprecated. + See also Deprecation + Warnings. +
+
+ A class (inheriting from Builder) that
+ takes
+ parsed documents and performs an action on them. Normally, builders
+ translate the documents to an output format, but it is also possible to
+ use builders that e.g. check for broken links in the documentation, or
+ build coverage information.
+
+ See Builders for an + overview over Sphinx\u2019s built-in + builders. +
+
+ The directory containing conf.py. By default, this is the
+ same as
+ the source
+ directory, but can be set differently with the -c
+ command-line option.
+
+ A reStructuredText markup element that allows marking a block of content + with special meaning. Directives are supplied not only by docutils, but + Sphinx and custom extensions can add their own. The basic directive + syntax looks like this: +
+.. directivename:: argument ...
+ :option: value
+
+ Content of the directive.
+
+ + See Directives for more information. +
+
+ Since reST source files can have different extensions (some people like
+ .txt, some like .rst \u2013 the extension can be
+ configured with
+ source_suffix)
+ and different OSes have different path
+ separators, Sphinx abstracts them: document names are always
+ relative to the source directory, the extension is stripped, and
+ path separators are converted to slashes. All values, parameters and such
+ referring to \u201cdocuments\u201d expect such document names.
+
+ Examples for document names are index, library/zipfile, or
+ reference/datamodel/types. Note that
+ there is no leading or trailing
+ slash.
+
+ A domain is a collection of markup (reStructuredText directives
+ and roles) to
+ describe and link to objects belonging
+ together, e.g. elements of a programming language. Directive and role
+ names in a domain have names like domain:name, e.g. py:function.
+
+ Having domains means that there are no naming problems when one set of + documentation wants to refer to e.g. C++ and Python classes. It also + means that extensions that support the documentation of whole new + languages are much easier to write. +
++ For more information, refer to Domains. +
++ A structure where information about all documents under the root is saved, + and used for cross-referencing. The environment is pickled after the + parsing stage, so that successive runs only need to read and parse new and + changed documents. +
++ A custom role, directive or + other aspect of Sphinx that + allows users to modify any aspect of the build process within Sphinx. +
++ For more information, refer to Extensions. +
+
+ The document that contains the root toctree directive.
+
+ The basic building block of Sphinx documentation. Every \u201cobject
+ directive\u201d (e.g. function or object) creates
+ such a
+ block; and most objects can be cross-referenced to.
+
+ An easy-to-read, what-you-see-is-what-you-get plaintext markup syntax and + parser system. +
+
+ A reStructuredText markup element that allows marking a piece of text.
+ Like directives, roles are extensible. The basic syntax looks like this:
+ :rolename:`content`. See Inline markup for details.
+
+ The directory which, including its subdirectories, contains all source + files for one Sphinx project. +
+
+ A class (inheriting from Builder) that
+ takes
+ parsed documents and performs an action on them. Normally, builders
+ translate the documents to an output format, but it is also possible to
+ use builders that e.g. check for broken links in the documentation, or
+ build coverage information.
+
+ See Builders for an + overview over Sphinx\u2019s built-in + builders. +
+
+ The directory containing conf.py. By default, this is the
+ same as
+ the source
+ directory, but can be set differently with the -c
+ command-line option.
+
+ A reStructuredText markup element that allows marking a block of content + with special meaning. Directives are supplied not only by docutils, but + Sphinx and custom extensions can add their own. The basic directive + syntax looks like this: +
+.. directivename:: argument ...
+ :option: value
+
+ Content of the directive.
+
+ + See Directives for more information. +
+
+ Since reST source files can have different extensions (some people like
+ .txt, some like .rst \u2013 the extension can be
+ configured with
+ source_suffix)
+ and different OSes have different path
+ separators, Sphinx abstracts them: document names are always
+ relative to the source directory, the extension is stripped, and
+ path separators are converted to slashes. All values, parameters and such
+ referring to \u201cdocuments\u201d expect such document names.
+
+ Examples for document names are index, library/zipfile, or
+ reference/datamodel/types. Note that
+ there is no leading or trailing
+ slash.
+
+ A domain is a collection of markup (reStructuredText directives
+ and roles) to
+ describe and link to objects belonging
+ together, e.g. elements of a programming language. Directive and role
+ names in a domain have names like domain:name, e.g. py:function.
+
+ Having domains means that there are no naming problems when one set of + documentation wants to refer to e.g. C++ and Python classes. It also + means that extensions that support the documentation of whole new + languages are much easier to write. +
++ For more information, refer to Domains. +
++ A structure where information about all documents under the root is saved, + and used for cross-referencing. The environment is pickled after the + parsing stage, so that successive runs only need to read and parse new and + changed documents. +
++ A custom role, directive or + other aspect of Sphinx that + allows users to modify any aspect of the build process within Sphinx. +
++ For more information, refer to Extensions. +
+
+ The document that contains the root toctree directive.
+
+ The basic building block of Sphinx documentation. Every \u201cobject
+ directive\u201d (e.g. function or object) creates
+ such a
+ block; and most objects can be cross-referenced to.
+
+ The feature which is warned will be removed in Sphinx-XXX version. + It usually caused from Sphinx extensions which is using deprecated. + See also Deprecation + Warnings. +
+
+ A reStructuredText markup element that allows marking a piece of text.
+ Like directives, roles are extensible. The basic syntax looks like this:
+ :rolename:`content`. See Inline markup for details.
+
+ The directory which, including its subdirectories, contains all source + files for one Sphinx project. +
++ An easy-to-read, what-you-see-is-what-you-get plaintext markup syntax and + parser system. +
+