[Cmake-commits] CMake branch, next, updated. v3.0.0-rc6-3475-g95c53e0

Brad King brad.king at kitware.com
Mon Jun 2 14:04:07 EDT 2014


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
       via  95c53e08026c350864173d1b9c4d283493270324 (commit)
       via  793b64e49922b3a7bf4b6afa23b4a14308330460 (commit)
       via  05bd31ab3ec5e0fc1e15c6504bf2e40b7d1c6a77 (commit)
       via  eaafe756d5046f9c0268cb9e8e596c2bb45555cc (commit)
       via  4207b3a3bb60a83aa9ea01f1288e426f3dc9e46b (commit)
      from  3a7ade01e0e31a943b721e3129f012d05adfa43d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=95c53e08026c350864173d1b9c4d283493270324
commit 95c53e08026c350864173d1b9c4d283493270324
Merge: 3a7ade0 793b64e
Author:     Brad King <brad.king at kitware.com>
AuthorDate: Mon Jun 2 14:04:06 2014 -0400
Commit:     CMake Topic Stage <kwrobot at kitware.com>
CommitDate: Mon Jun 2 14:04:06 2014 -0400

    Merge topic 'doc-section-header-convention' into next
    
    793b64e4 Help: Document section header underline hierarchy in cmake-developer.7
    05bd31ab Help: Organize documentation style sections in cmake-developer.7
    eaafe756 Help: Add documentation style section headers to cmake-developer.7
    4207b3a3 Help: Use "^^^^" for subsubsection headers


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=793b64e49922b3a7bf4b6afa23b4a14308330460
commit 793b64e49922b3a7bf4b6afa23b4a14308330460
Author:     Brad King <brad.king at kitware.com>
AuthorDate: Mon Jun 2 13:59:35 2014 -0400
Commit:     Brad King <brad.king at kitware.com>
CommitDate: Mon Jun 2 14:04:00 2014 -0400

    Help: Document section header underline hierarchy in cmake-developer.7
    
    Explicitly specify the sequence of underline characters we use in the
    CMake documentation.  It is the same sequence as that suggested in the
    Sphinx documentation, but we have our own descriptions.

diff --git a/Help/manual/cmake-developer.7.rst b/Help/manual/cmake-developer.7.rst
index 9476d64..9851c12 100644
--- a/Help/manual/cmake-developer.7.rst
+++ b/Help/manual/cmake-developer.7.rst
@@ -479,6 +479,15 @@ example:
 
 Capitalize the first letter of each non-minor word in the title.
 
+The section header underline character hierarchy is
+
+* ``#``: Manual group (part) in the master document
+* ``*``: Manual (chapter) title
+* ``=``: Section within a manual
+* ``-``: Subsection or `CMake Domain`_ object document title
+* ``^``: Subsubsection or `CMake Domain`_ object document section
+* ``"``: Paragraph or `CMake Domain`_ object document subsection
+
 Style: Whitespace
 ^^^^^^^^^^^^^^^^^
 

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=05bd31ab3ec5e0fc1e15c6504bf2e40b7d1c6a77
commit 05bd31ab3ec5e0fc1e15c6504bf2e40b7d1c6a77
Author:     Brad King <brad.king at kitware.com>
AuthorDate: Mon Jun 2 13:58:28 2014 -0400
Commit:     Brad King <brad.king at kitware.com>
CommitDate: Mon Jun 2 14:02:47 2014 -0400

    Help: Organize documentation style sections in cmake-developer.7
    
    Now that the style guidelines have section titles instead of numbers,
    organize them into more well-defined sections.

diff --git a/Help/manual/cmake-developer.7.rst b/Help/manual/cmake-developer.7.rst
index 53a4f56..9476d64 100644
--- a/Help/manual/cmake-developer.7.rst
+++ b/Help/manual/cmake-developer.7.rst
@@ -465,35 +465,19 @@ with an explicit target.
 Style
 -----
 
-Style: Command Signatures
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Command signatures should be marked up as plain literal blocks, not as
-cmake ``code-blocks``.
+Style: Section Headers
+^^^^^^^^^^^^^^^^^^^^^^
 
-Signatures are separated from preceding content by a horizontal
-line. That is, use:
+When marking section titles, make the section decoration line as long as
+the title text.  Use only a line below the title, not above. For
+example:
 
 .. code-block:: rst
 
-  ... preceding paragraph.
-
-  ---------------------------------------------------------------------
-
-  ::
-
-    add_library(<lib> ...)
-
-  This signature is used for ...
-
-Style: Boolean Constants
-^^^^^^^^^^^^^^^^^^^^^^^^
+  Title Text
+  ----------
 
-Use "``OFF``" and "``ON``" for boolean values which can be modified by
-the user, such as :prop_tgt:`POSITION_INDEPENDENT_CODE`. Such properties
-may be "enabled" and "disabled". Use "``True``" and "``False``" for
-inherent values which can't be modified after being set, such as the
-:prop_tgt:`IMPORTED` property of a build target.
+Capitalize the first letter of each non-minor word in the title.
 
 Style: Whitespace
 ^^^^^^^^^^^^^^^^^
@@ -501,14 +485,6 @@ Style: Whitespace
 Use two spaces for indentation.  Use two spaces between sentences in
 prose.
 
-Style: Starting Literal Blocks
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Prefer to mark the start of literal blocks with ``::`` at the end of
-the preceding paragraph. In cases where the following block gets
-a ``code-block`` marker, put a single ``:`` at the end of the preceding
-paragraph.
-
 Style: Line Length
 ^^^^^^^^^^^^^^^^^^
 
@@ -517,37 +493,60 @@ hard restriction, but writing new paragraphs wrapped at 75 columns
 allows space for adding minor content without significant re-wrapping of
 content.
 
-Style: Document Self-References
+Style: Prose
+^^^^^^^^^^^^
+
+Use American English spellings in prose.
+
+Style: Starting Literal Blocks
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Prefer to mark the start of literal blocks with ``::`` at the end of
+the preceding paragraph. In cases where the following block gets
+a ``code-block`` marker, put a single ``:`` at the end of the preceding
+paragraph.
+
+Style: CMake Command Signatures
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Mark up self-references with  ``inline-literal`` syntax. For example,
-within the add_executable command documentation, use
+Command signatures should be marked up as plain literal blocks, not as
+cmake ``code-blocks``.
+
+Signatures are separated from preceding content by a horizontal
+line. That is, use:
 
 .. code-block:: rst
 
-  ``add_executable``
+  ... preceding paragraph.
 
-not
+  ---------------------------------------------------------------------
 
-.. code-block:: rst
+  ::
 
-  :command:`add_executable`
+    add_library(<lib> ...)
 
-which is used elsewhere.
+  This signature is used for ...
 
-Style: Linkable References
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+Signatures of commands should wrap optional parts with square brackets,
+and should mark list of optional arguments with an ellipsis (``...``).
+Elements of the signature which are specified by the user should be
+specified with angle brackets, and may be referred to in prose using
+``inline-literal`` syntax.
 
-Mark up all other linkable references as links, including repeats. An
-alternative, which is used by wikipedia (`<http://en.wikipedia.org/wiki/WP:REPEATLINK>`_),
-is to link to a reference only once per article. That style is not used
-in CMake documentation.
+Style: Boolean Constants
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use "``OFF``" and "``ON``" for boolean values which can be modified by
+the user, such as :prop_tgt:`POSITION_INDEPENDENT_CODE`. Such properties
+may be "enabled" and "disabled". Use "``True``" and "``False``" for
+inherent values which can't be modified after being set, such as the
+:prop_tgt:`IMPORTED` property of a build target.
 
-Style: Technical Terms
+Style: Inline Literals
 ^^^^^^^^^^^^^^^^^^^^^^
 
 Mark up references to keywords in signatures, file names, and other
-technical terms with ``inline-literl`` syntax, for example:
+technical terms with ``inline-literal`` syntax, for example:
 
 .. code-block:: rst
 
@@ -555,8 +554,17 @@ technical terms with ``inline-literl`` syntax, for example:
   :prop_tgt:`WIN32_EXECUTABLE` target property is enabled. That command
   creates the file ``<name>.exe`` on Windows.
 
-Style: Referencing Concepts
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Style: Cross-References
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Mark up linkable references as links, including repeats.
+An alternative, which is used by wikipedia
+(`<http://en.wikipedia.org/wiki/WP:REPEATLINK>`_),
+is to link to a reference only once per article. That style is not used
+in CMake documentation.
+
+Style: Referencing CMake Concepts
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 If referring to a concept which corresponds to a property, and that
 concept is described in a high-level manual, prefer to link to the
@@ -598,26 +606,12 @@ link to the primary manual, which provides high-level information.  Only
 particular information relating to the command should be in the
 documentation of the command.
 
-Style: Section Titles
-^^^^^^^^^^^^^^^^^^^^^
-
-When marking section titles, make the section decoration line as long as
-the title text.  Use only a line below the title, not above. For
-example:
-
-.. code-block:: rst
-
-  Title Text
-  ----------
-
-Capitalize the first letter of each non-minor word in the title.
-
 Style: Referencing CMake Domain Objects
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-When referring to properties, variables, commands etc, prefer to link
-to the target object and follow that with the type of object it is.
-For example:
+When referring to `CMake Domain`_ objects such as properties, variables,
+commands etc, prefer to link to the target object and follow that with
+the type of object it is.  For example:
 
 .. code-block:: rst
 
@@ -636,19 +630,21 @@ referred to before the link:
 
   If policy :prop_tgt:`CMP0022` is set to ``NEW`` the behavior is ...
 
-Style: Command Signature Markup
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+However, markup self-references with ``inline-literal`` syntax.
+For example, within the :command:`add_executable` command
+documentation, use
 
-Signatures of commands should wrap optional parts with square brackets,
-and should mark list of optional arguments with an ellipsis (``...``).
-Elements of the signature which are specified by the user should be
-specified with angle brackets, and may be referred to in prose using
-``inline-literal`` syntax.
+.. code-block:: rst
 
-Style: Prose
-^^^^^^^^^^^^
+  ``add_executable``
 
-Use American English spellings in prose.
+not
+
+.. code-block:: rst
+
+  :command:`add_executable`
+
+which is used elsewhere.
 
 Modules
 =======

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eaafe756d5046f9c0268cb9e8e596c2bb45555cc
commit eaafe756d5046f9c0268cb9e8e596c2bb45555cc
Author:     Brad King <brad.king at kitware.com>
AuthorDate: Mon Jun 2 13:58:01 2014 -0400
Commit:     Brad King <brad.king at kitware.com>
CommitDate: Mon Jun 2 14:01:24 2014 -0400

    Help: Add documentation style section headers to cmake-developer.7
    
    Give the style guides titles instead of numbers so we can link to them.

diff --git a/Help/manual/cmake-developer.7.rst b/Help/manual/cmake-developer.7.rst
index b26835f..53a4f56 100644
--- a/Help/manual/cmake-developer.7.rst
+++ b/Help/manual/cmake-developer.7.rst
@@ -465,168 +465,190 @@ with an explicit target.
 Style
 -----
 
-1)
-  Command signatures should be marked up as plain literal blocks, not as
-  cmake ``code-blocks``.
+Style: Command Signatures
+^^^^^^^^^^^^^^^^^^^^^^^^^
 
-2)
-  Signatures are separated from preceding content by a horizontal
-  line. That is, use:
+Command signatures should be marked up as plain literal blocks, not as
+cmake ``code-blocks``.
 
-  .. code-block:: rst
+Signatures are separated from preceding content by a horizontal
+line. That is, use:
 
-    ... preceding paragraph.
+.. code-block:: rst
+
+  ... preceding paragraph.
+
+  ---------------------------------------------------------------------
+
+  ::
+
+    add_library(<lib> ...)
+
+  This signature is used for ...
+
+Style: Boolean Constants
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use "``OFF``" and "``ON``" for boolean values which can be modified by
+the user, such as :prop_tgt:`POSITION_INDEPENDENT_CODE`. Such properties
+may be "enabled" and "disabled". Use "``True``" and "``False``" for
+inherent values which can't be modified after being set, such as the
+:prop_tgt:`IMPORTED` property of a build target.
+
+Style: Whitespace
+^^^^^^^^^^^^^^^^^
+
+Use two spaces for indentation.  Use two spaces between sentences in
+prose.
+
+Style: Starting Literal Blocks
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-    ---------------------------------------------------------------------
+Prefer to mark the start of literal blocks with ``::`` at the end of
+the preceding paragraph. In cases where the following block gets
+a ``code-block`` marker, put a single ``:`` at the end of the preceding
+paragraph.
 
-    ::
+Style: Line Length
+^^^^^^^^^^^^^^^^^^
 
-      add_library(<lib> ...)
+Prefer to restrict the width of lines to 75-80 columns.  This is not a
+hard restriction, but writing new paragraphs wrapped at 75 columns
+allows space for adding minor content without significant re-wrapping of
+content.
 
-    This signature is used for ...
+Style: Document Self-References
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-3)
-  Use "``OFF``" and "``ON``" for boolean values which can be modified by
-  the user, such as :prop_tgt:`POSITION_INDEPENDENT_CODE`. Such properties
-  may be "enabled" and "disabled". Use "``True``" and "``False``" for
-  inherent values which can't be modified after being set, such as the
-  :prop_tgt:`IMPORTED` property of a build target.
+Mark up self-references with  ``inline-literal`` syntax. For example,
+within the add_executable command documentation, use
 
-4)
-  Use two spaces for indentation.  Use two spaces between sentences in
-  prose.
+.. code-block:: rst
 
-5)
-  Prefer to mark the start of literal blocks with ``::`` at the end of
-  the preceding paragraph. In cases where the following block gets
-  a ``code-block`` marker, put a single ``:`` at the end of the preceding
-  paragraph.
+  ``add_executable``
 
-6)
-  Prefer to restrict the width of lines to 75-80 columns.  This is not a
-  hard restriction, but writing new paragraphs wrapped at 75 columns
-  allows space for adding minor content without significant re-wrapping of
-  content.
+not
 
-7)
-  Mark up self-references with  ``inline-literal`` syntax. For example,
-  within the add_executable command documentation, use
+.. code-block:: rst
 
-  .. code-block:: rst
+  :command:`add_executable`
 
-    ``add_executable``
+which is used elsewhere.
 
-  not
+Style: Linkable References
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-  .. code-block:: rst
+Mark up all other linkable references as links, including repeats. An
+alternative, which is used by wikipedia (`<http://en.wikipedia.org/wiki/WP:REPEATLINK>`_),
+is to link to a reference only once per article. That style is not used
+in CMake documentation.
 
-    :command:`add_executable`
+Style: Technical Terms
+^^^^^^^^^^^^^^^^^^^^^^
 
-  which is used elsewhere.
+Mark up references to keywords in signatures, file names, and other
+technical terms with ``inline-literl`` syntax, for example:
 
-8)
-  Mark up all other linkable references as links, including repeats. An
-  alternative, which is used by wikipedia (`<http://en.wikipedia.org/wiki/WP:REPEATLINK>`_),
-  is to link to a reference only once per article. That style is not used
-  in CMake documentation.
+.. code-block:: rst
 
-9)
-  Mark up references to keywords in signatures, file names, and other
-  technical terms with ``inline-literl`` syntax, for example:
+  If ``WIN32`` is used with :command:`add_executable`, the
+  :prop_tgt:`WIN32_EXECUTABLE` target property is enabled. That command
+  creates the file ``<name>.exe`` on Windows.
 
-  .. code-block:: rst
+Style: Referencing Concepts
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-    If ``WIN32`` is used with :command:`add_executable`, the
-    :prop_tgt:`WIN32_EXECUTABLE` target property is enabled. That command
-    creates the file ``<name>.exe`` on Windows.
+If referring to a concept which corresponds to a property, and that
+concept is described in a high-level manual, prefer to link to the
+manual section instead of the property. For example:
 
+.. code-block:: rst
 
-10)
-  If referring to a concept which corresponds to a property, and that
-  concept is described in a high-level manual, prefer to link to the
-  manual section instead of the property. For example:
+  This command creates an :ref:`Imported Target <Imported Targets>`.
 
-  .. code-block:: rst
+instead of:
 
-    This command creates an :ref:`Imported Target <Imported Targets>`.
+.. code-block:: rst
 
-  instead of:
+  This command creates an :prop_tgt:`IMPORTED` target.
 
-  .. code-block:: rst
+The latter should be used only when referring specifically to the
+property.
 
-    This command creates an :prop_tgt:`IMPORTED` target.
+References to manual sections are not automatically created by creating
+a section, but code such as:
 
-  The latter should be used only when referring specifically to the
-  property.
+.. code-block:: rst
 
-  References to manual sections are not automatically created by creating
-  a section, but code such as:
+  .. _`Imported Targets`:
 
-  .. code-block:: rst
+creates a suitable anchor.  Use an anchor name which matches the name
+of the corresponding section.  Refer to the anchor using a
+cross-reference with specified text.
 
-    .. _`Imported Targets`:
+Imported Targets need the ``IMPORTED`` term marked up with care in
+particular because the term may refer to a command keyword
+(``IMPORTED``), a target property (:prop_tgt:`IMPORTED`), or a
+concept (:ref:`Imported Targets`).
 
-  creates a suitable anchor.  Use an anchor name which matches the name
-  of the corresponding section.  Refer to the anchor using a
-  cross-reference with specified text.
+Where a property, command or variable is related conceptually to others,
+by for example, being related to the buildsystem description, generator
+expressions or Qt, each relevant property, command or variable should
+link to the primary manual, which provides high-level information.  Only
+particular information relating to the command should be in the
+documentation of the command.
 
-  Imported Targets need the ``IMPORTED`` term marked up with care in
-  particular because the term may refer to a command keyword
-  (``IMPORTED``), a target property (:prop_tgt:`IMPORTED`), or a
-  concept (:ref:`Imported Targets`).
+Style: Section Titles
+^^^^^^^^^^^^^^^^^^^^^
 
-11)
-  Where a property, command or variable is related conceptually to others,
-  by for example, being related to the buildsystem description, generator
-  expressions or Qt, each relevant property, command or variable should
-  link to the primary manual, which provides high-level information.  Only
-  particular information relating to the command should be in the
-  documentation of the command.
+When marking section titles, make the section decoration line as long as
+the title text.  Use only a line below the title, not above. For
+example:
 
-12)
-  When marking section titles, make the section decoration line as long as
-  the title text.  Use only a line below the title, not above. For
-  example:
+.. code-block:: rst
 
-  .. code-block:: rst
+  Title Text
+  ----------
 
-    Title Text
-    ----------
+Capitalize the first letter of each non-minor word in the title.
 
-  Capitalize the first letter of each non-minor word in the title.
+Style: Referencing CMake Domain Objects
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-13)
-  When referring to properties, variables, commands etc, prefer to link
-  to the target object and follow that with the type of object it is.
-  For example:
+When referring to properties, variables, commands etc, prefer to link
+to the target object and follow that with the type of object it is.
+For example:
 
-  .. code-block:: rst
+.. code-block:: rst
 
-    Set the :prop_tgt:`AUTOMOC` target property to ``ON``.
+  Set the :prop_tgt:`AUTOMOC` target property to ``ON``.
 
-  Instead of
+Instead of
 
-  .. code-block:: rst
+.. code-block:: rst
 
-    Set the target property :prop_tgt:`AUTOMOC` to ``ON``.
+  Set the target property :prop_tgt:`AUTOMOC` to ``ON``.
 
-  The ``policy`` directive is an exception, and the type us usually
-  referred to before the link:
+The ``policy`` directive is an exception, and the type us usually
+referred to before the link:
+
+.. code-block:: rst
 
-  .. code-block:: rst
+  If policy :prop_tgt:`CMP0022` is set to ``NEW`` the behavior is ...
 
-    If policy :prop_tgt:`CMP0022` is set to ``NEW`` the behavior is ...
+Style: Command Signature Markup
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-14)
-  Signatures of commands should wrap optional parts with square brackets,
-  and should mark list of optional arguments with an ellipsis (``...``).
-  Elements of the signature which are specified by the user should be
-  specified with angle brackets, and may be referred to in prose using
-  ``inline-literal`` syntax.
+Signatures of commands should wrap optional parts with square brackets,
+and should mark list of optional arguments with an ellipsis (``...``).
+Elements of the signature which are specified by the user should be
+specified with angle brackets, and may be referred to in prose using
+``inline-literal`` syntax.
 
-15)
-  Use American English spellings in prose.
+Style: Prose
+^^^^^^^^^^^^
 
+Use American English spellings in prose.
 
 Modules
 =======

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4207b3a3bb60a83aa9ea01f1288e426f3dc9e46b
commit 4207b3a3bb60a83aa9ea01f1288e426f3dc9e46b
Author:     Brad King <brad.king at kitware.com>
AuthorDate: Mon Jun 2 13:16:28 2014 -0400
Commit:     Brad King <brad.king at kitware.com>
CommitDate: Mon Jun 2 14:00:33 2014 -0400

    Help: Use "^^^^" for subsubsection headers
    
    This is the convention suggested in the Sphinx documentation and is
    already used in several other places in the CMake documentation.
    Update a few places where we were using other characters.

diff --git a/Help/command/cmake_policy.rst b/Help/command/cmake_policy.rst
index b14a2aa..2bc3287 100644
--- a/Help/command/cmake_policy.rst
+++ b/Help/command/cmake_policy.rst
@@ -18,7 +18,7 @@ setting is available the ``OLD`` behavior is assumed and a warning is
 produced requesting that the policy be set.
 
 Setting Policies by CMake Version
-'''''''''''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The ``cmake_policy`` command is used to set policies to ``OLD`` or ``NEW``
 behavior.  While setting policies individually is supported, we
@@ -40,7 +40,7 @@ Note that the :command:`cmake_minimum_required(VERSION)`
 command implicitly calls ``cmake_policy(VERSION)`` too.
 
 Setting Policies Explicitly
-'''''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
@@ -54,7 +54,7 @@ one may fix the project to work with the new behavior and set the
 policy state to ``NEW``.
 
 Checking Policy Settings
-''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
@@ -65,7 +65,7 @@ The output ``<variable>`` value will be ``OLD`` or ``NEW`` if the
 policy is set, and empty otherwise.
 
 CMake Policy Stack
-''''''''''''''''''
+^^^^^^^^^^^^^^^^^^
 
 CMake keeps policy settings on a stack, so changes made by the
 cmake_policy command affect only the top of the stack.  A new entry on
diff --git a/Help/manual/cmake-buildsystem.7.rst b/Help/manual/cmake-buildsystem.7.rst
index 3e1f011..f3616fb 100644
--- a/Help/manual/cmake-buildsystem.7.rst
+++ b/Help/manual/cmake-buildsystem.7.rst
@@ -551,7 +551,7 @@ exporting see the :manual:`cmake-packages(7)` manual.
 .. _`Include Directories and Usage Requirements`:
 
 Include Directories and Usage Requirements
-''''''''''''''''''''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Include directories require some special consideration when specified as usage
 requirements and when used with generator expressions.  The
diff --git a/Help/manual/cmake-developer.7.rst b/Help/manual/cmake-developer.7.rst
index 81adea0..b26835f 100644
--- a/Help/manual/cmake-developer.7.rst
+++ b/Help/manual/cmake-developer.7.rst
@@ -808,7 +808,7 @@ Documentation`_ section above.
 
 
 Standard Variable Names
-~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^
 
 For a ``FindXxx.cmake`` module that takes the approach of setting
 variables (either instead of or in addition to creating imported
@@ -914,7 +914,7 @@ them.
 
 
 A Sample Find Module
-~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^
 
 We will describe how to create a simple find module for a library
 ``Foo``.
diff --git a/Help/manual/cmake-qt.7.rst b/Help/manual/cmake-qt.7.rst
index cad4951..fe8d62d 100644
--- a/Help/manual/cmake-qt.7.rst
+++ b/Help/manual/cmake-qt.7.rst
@@ -54,7 +54,7 @@ CMake.  Target dependencies may be added to that custom target by adding them
 to the :prop_tgt:`AUTOGEN_TARGET_DEPENDS` target property.
 
 AUTOMOC
-'''''''
+^^^^^^^
 
 The :prop_tgt:`AUTOMOC` target property controls whether :manual:`cmake(1)`
 inspects the C++ files in the target to determine if they require ``moc`` to
@@ -84,7 +84,7 @@ variable may be populated to pre-set the options for all following targets.
 .. _`Qt AUTOUIC`:
 
 AUTOUIC
-'''''''
+^^^^^^^
 
 The :prop_tgt:`AUTOUIC` target property controls whether :manual:`cmake(1)`
 inspects the C++ files in the target to determine if they require ``uic`` to
@@ -147,7 +147,7 @@ result of linking with the :prop_tgt:`IMPORTED` target:
 .. _`Qt AUTORCC`:
 
 AUTORCC
-'''''''
+^^^^^^^
 
 The :prop_tgt:`AUTORCC` target property controls whether :manual:`cmake(1)`
 creates rules to execute ``rcc`` at the appropriate time on source files

-----------------------------------------------------------------------

Summary of changes:
 Help/command/cmake_policy.rst       |    8 +-
 Help/manual/cmake-buildsystem.7.rst |    2 +-
 Help/manual/cmake-developer.7.rst   |  251 +++++++++++++++++++----------------
 Help/manual/cmake-qt.7.rst          |    6 +-
 4 files changed, 147 insertions(+), 120 deletions(-)


hooks/post-receive
-- 
CMake


More information about the Cmake-commits mailing list