[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7453-ga31f1a2
Stephen Kelly
steveire at gmail.com
Wed Feb 5 09:42:23 EST 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 a31f1a20e4b50c1ba741e4875b9eb331553834de (commit)
via 90201642df6f128c84bb0c7c21682effd61b7dcd (commit)
via 3978473a00bc8a500d8ce406e04aec06ce10a530 (commit)
via 1ab9a085e301f0b278442a2f87cabd15510c6386 (commit)
via fb94fb0bf215e447728c92e0d5997226bd4d8909 (commit)
via ff6661d4abe197e89cb3be0e707cc7e16abb7a39 (commit)
via ad2e8e7ceda0004183ff230ca6fa590f4e826dc2 (commit)
via f1c86097f4411309ffb9da08758e2ca3909f9f95 (commit)
via 7b5c5c67f447eafeb9c0af251a103e4577c4c8b3 (commit)
via cf059f54aef337a7e0528a756e0df114709c09f4 (commit)
via 7f99a9a7b17db365520513822538311a340821d3 (commit)
via 13fd94ae6d59009d208e272349cdacb42441105d (commit)
from b02d915d28c000a4fa69ee7465d17bf4c9f13239 (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=a31f1a20e4b50c1ba741e4875b9eb331553834de
commit a31f1a20e4b50c1ba741e4875b9eb331553834de
Merge: b02d915 9020164
Author: Stephen Kelly <steveire at gmail.com>
AuthorDate: Wed Feb 5 09:42:21 2014 -0500
Commit: CMake Topic Stage <kwrobot at kitware.com>
CommitDate: Wed Feb 5 09:42:21 2014 -0500
Merge topic 'update-buildsystem-docs' into next
90201642 Help: Adjust the QtAutogen properties to the common style.
3978473a Help: Use ``True`` and ``False`` for IMPORTED values.
1ab9a085 Help: Document relation of properties to the rest of the buildsystem.
fb94fb0b Help: Mark up the buildsystem commands documentation
ff6661d4 Help: Note that the compatible interface properties must not intersect.
ad2e8e7c Help: Specify how to order and modify transitively set property values.
f1c86097 Help: Add references to manual sections.
7b5c5c67 Help: Use ``inline-literals`` to mark generator expressions.
cf059f54 Help: Mark up references to NEW and OLD policy settings properly.
7f99a9a7 Help: Add a style guide.
13fd94ae Help: Fix typos
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=90201642df6f128c84bb0c7c21682effd61b7dcd
commit 90201642df6f128c84bb0c7c21682effd61b7dcd
Author: Stephen Kelly <steveire at gmail.com>
AuthorDate: Wed Feb 5 15:17:45 2014 +0100
Commit: Stephen Kelly <steveire at gmail.com>
CommitDate: Wed Feb 5 15:41:54 2014 +0100
Help: Adjust the QtAutogen properties to the common style.
Link to the cmake-qt manual.
diff --git a/Help/prop_tgt/AUTOGEN_TARGET_DEPENDS.rst b/Help/prop_tgt/AUTOGEN_TARGET_DEPENDS.rst
index 3e6c4d1..5063244 100644
--- a/Help/prop_tgt/AUTOGEN_TARGET_DEPENDS.rst
+++ b/Help/prop_tgt/AUTOGEN_TARGET_DEPENDS.rst
@@ -3,7 +3,7 @@ AUTOGEN_TARGET_DEPENDS
Target dependencies of the corresponding ``_automoc`` target.
-Targets which have their :prop_tgt:`AUTOMOC` target set to ``TRUE`` have a
+Targets which have their :prop_tgt:`AUTOMOC` target ``ON`` have a
corresponding ``_automoc`` target which is used to autogenerate generate moc
files. As this ``_automoc`` target is created at generate-time, it is not
possible to define dependencies of it, such as to create inputs for the ``moc``
@@ -12,3 +12,6 @@ executable.
The ``AUTOGEN_TARGET_DEPENDS`` target property can be set instead to a list of
dependencies for the ``_automoc`` target. The buildsystem will be generated to
depend on its contents.
+
+See the :manual:`cmake-qt(7)` manual for more information on using CMake
+with Qt.
diff --git a/Help/prop_tgt/AUTOMOC.rst b/Help/prop_tgt/AUTOMOC.rst
index 5e07063..045ebb2 100644
--- a/Help/prop_tgt/AUTOMOC.rst
+++ b/Help/prop_tgt/AUTOMOC.rst
@@ -6,7 +6,7 @@ Should the target be processed with automoc (for Qt projects).
AUTOMOC is a boolean specifying whether CMake will handle the Qt ``moc``
preprocessor automatically, i.e. without having to use the
:module:`QT4_WRAP_CPP() <FindQt4>` or QT5_WRAP_CPP() macro. Currently Qt4 and Qt5 are
-supported. When this property is set to ``TRUE``, CMake will scan the
+supported. When this property is set ``ON``, CMake will scan the
source files at build time and invoke moc accordingly. If an ``#include``
statement like ``#include "moc_foo.cpp"`` is found, the ``Q_OBJECT`` class
declaration is expected in the header, and ``moc`` is run on the header
@@ -20,15 +20,18 @@ for ``Q_OBJECT`` macros, and if found, ``moc`` is also executed on those files.
The resulting moc files, which are not included as shown above in any
of the source files are included in a generated
``<targetname>_automoc.cpp`` file, which is compiled as part of the
-target. This property is initialized by the value of the variable
-:variable:`CMAKE_AUTOMOC` if it is set when a target is created.
+target. This property is initialized by the value of the
+:variable:`CMAKE_AUTOMOC` variable if it is set when a target is created.
Additional command line options for moc can be set via the
:prop_tgt:`AUTOMOC_MOC_OPTIONS` property.
-By setting the :variable:`CMAKE_AUTOMOC_RELAXED_MODE` variable to ``TRUE`` the
+By enabling the :variable:`CMAKE_AUTOMOC_RELAXED_MODE` variable the
rules for searching the files which will be processed by moc can be relaxed.
See the documentation for this variable for more details.
-The global property :prop_gbl:`AUTOMOC_TARGETS_FOLDER` can be used to group the
+The global property :prop_gbl:`AUTOGEN_TARGETS_FOLDER` can be used to group the
automoc targets together in an IDE, e.g. in MSVS.
+
+See the :manual:`cmake-qt(7)` manual for more information on using CMake
+with Qt.
diff --git a/Help/prop_tgt/AUTOMOC_MOC_OPTIONS.rst b/Help/prop_tgt/AUTOMOC_MOC_OPTIONS.rst
index d086bf5..ebd5c49 100644
--- a/Help/prop_tgt/AUTOMOC_MOC_OPTIONS.rst
+++ b/Help/prop_tgt/AUTOMOC_MOC_OPTIONS.rst
@@ -3,10 +3,13 @@ AUTOMOC_MOC_OPTIONS
Additional options for moc when using :prop_tgt:`AUTOMOC`
-This property is only used if the :prop_tgt:`AUTOMOC` property is set to ``TRUE``
-for this target. In this case, it holds additional command line options
-which will be used when ``moc`` is executed during the build, i.e. it is
-equivalent to the optional ``OPTIONS`` argument of the :module:`qt4_wrap_cpp() <FindQt4>`
-macro.
+This property is only used if the :prop_tgt:`AUTOMOC` property is ``ON``
+for this target. In this case, it holds additional command line
+options which will be used when ``moc`` is executed during the build, i.e.
+it is equivalent to the optional ``OPTIONS`` argument of the
+:module:`qt4_wrap_cpp() <FindQt4>` macro.
By default it is empty.
+
+See the :manual:`cmake-qt(7)` manual for more information on using CMake
+with Qt.
diff --git a/Help/prop_tgt/AUTORCC.rst b/Help/prop_tgt/AUTORCC.rst
index f6409ea..8dce6b1 100644
--- a/Help/prop_tgt/AUTORCC.rst
+++ b/Help/prop_tgt/AUTORCC.rst
@@ -1,4 +1,3 @@
-
AUTORCC
-------
@@ -6,10 +5,10 @@ Should the target be processed with autorcc (for Qt projects).
``AUTORCC`` is a boolean specifying whether CMake will handle
the Qt ``rcc`` code generator automatically, i.e. without having to use
-the :module:`QT4_ADD_RESOURCES() <FindQt4>` or QT5_ADD_RESOURCES() macro.
-Currently Qt4 and Qt5 are supported.
+the :module:`QT4_ADD_RESOURCES() <FindQt4>` or ``QT5_ADD_RESOURCES()``
+macro. Currently Qt4 and Qt5 are supported.
-When this property is set to ``TRUE``, CMake will handle ``.qrc`` files added
+When this property is ``ON``, CMake will handle ``.qrc`` files added
as target sources at build time and invoke ``rcc`` accordingly.
This property is initialized by the value of the :variable:`CMAKE_AUTORCC`
variable if it is set when a target is created.
@@ -17,5 +16,8 @@ variable if it is set when a target is created.
Additional command line options for rcc can be set via the
:prop_sf:`AUTORCC_OPTIONS` source file property on the ``.qrc`` file.
-The global property :prop_gbl:`AUTOGEN_TARGETS_FOLDER` can be used to group the
-autouic targets together in an IDE, e.g. in MSVS.
+The global property :prop_gbl:`AUTOGEN_TARGETS_FOLDER` can be used to group
+the autorcc targets together in an IDE, e.g. in MSVS.
+
+See the :manual:`cmake-qt(7)` manual for more information on using CMake
+with Qt.
diff --git a/Help/prop_tgt/AUTORCC_OPTIONS.rst b/Help/prop_tgt/AUTORCC_OPTIONS.rst
index 1dd82ee..8a0f632 100644
--- a/Help/prop_tgt/AUTORCC_OPTIONS.rst
+++ b/Help/prop_tgt/AUTORCC_OPTIONS.rst
@@ -3,15 +3,19 @@ AUTORCC_OPTIONS
Additional options for ``rcc`` when using :prop_tgt:`AUTORCC`
-This property holds additional command line options
-which will be used when ``rcc`` is executed during the build via :prop_tgt:`AUTORCC`,
+This property holds additional command line options which will be used
+when ``rcc`` is executed during the build via :prop_tgt:`AUTORCC`,
i.e. it is equivalent to the optional ``OPTIONS`` argument of the
:module:`qt4_add_resources() <FindQt4>` macro.
By default it is empty.
-This property is initialized by the value of the variable
-:variable:`CMAKE_AUTORCC` if it is set when a target is created.
+This property is initialized by the value of the
+:variable:`CMAKE_AUTORCC_OPTIONS` variable if it is set when a target is
+created.
-The options set on the target may be overridden by :prop_sf:`AUTORCC_OPTIONS` set
-on the ``.qrc`` source file.
+The options set on the target may be overridden by :prop_sf:`AUTORCC_OPTIONS`
+set on the ``.qrc`` source file.
+
+See the :manual:`cmake-qt(7)` manual for more information on using CMake
+with Qt.
diff --git a/Help/prop_tgt/AUTOUIC.rst b/Help/prop_tgt/AUTOUIC.rst
index 010c027..4e60ec3 100644
--- a/Help/prop_tgt/AUTOUIC.rst
+++ b/Help/prop_tgt/AUTOUIC.rst
@@ -5,18 +5,20 @@ Should the target be processed with autouic (for Qt projects).
``AUTOUIC`` is a boolean specifying whether CMake will handle
the Qt ``uic`` code generator automatically, i.e. without having to use
-the :module:`QT4_WRAP_UI() <FindQt4>` or QT5_WRAP_UI() macro. Currently Qt4
-and Qt5 are supported.
+the :module:`QT4_WRAP_UI() <FindQt4>` or ``QT5_WRAP_UI()`` macro. Currently
+Qt4 and Qt5 are supported.
-When this property is set to ``TRUE``, CMake will scan the source files
-at build time and invoke ``uic`` accordingly.
-If an ``#include`` statement like ``#include "ui_foo.h"`` is found in
-``foo.cpp``, a ``foo.ui`` file is expected next to ``foo.cpp``, and ``uic`` is
-run on the ``foo.ui`` file.
+When this property is ``ON``, CMake will scan the source files at build time
+and invoke ``uic`` accordingly. If an ``#include`` statement like
+``#include "ui_foo.h"`` is found in ``foo.cpp``, a ``foo.ui`` file is
+expected next to ``foo.cpp``, and ``uic`` is run on the ``foo.ui`` file.
This property is initialized by the value of the :variable:`CMAKE_AUTOUIC`
variable if it is set when a target is created.
-Additional command line options for uic can be set via the
+Additional command line options for ``uic`` can be set via the
:prop_sf:`AUTOUIC_OPTIONS` source file property on the ``foo.ui`` file.
The global property :prop_gbl:`AUTOGEN_TARGETS_FOLDER` can be used to group the
autouic targets together in an IDE, e.g. in MSVS.
+
+See the :manual:`cmake-qt(7)` manual for more information on using CMake
+with Qt.
diff --git a/Help/prop_tgt/AUTOUIC_OPTIONS.rst b/Help/prop_tgt/AUTOUIC_OPTIONS.rst
index 2571634..dc3bee5 100644
--- a/Help/prop_tgt/AUTOUIC_OPTIONS.rst
+++ b/Help/prop_tgt/AUTOUIC_OPTIONS.rst
@@ -3,19 +3,23 @@ AUTOUIC_OPTIONS
Additional options for uic when using :prop_tgt:`AUTOUIC`
-This property holds additional command line options
-which will be used when ``uic`` is executed during the build via :prop_tgt:`AUTOUIC`,
-i.e. it is equivalent to the optional ``OPTIONS`` argument of the
+This property holds additional command line options which will be used when
+``uic`` is executed during the build via :prop_tgt:`AUTOUIC`, i.e. it is
+equivalent to the optional ``OPTIONS`` argument of the
:module:`qt4_wrap_ui() <FindQt4>` macro.
By default it is empty.
-This property is initialized by the value of the variable
-:variable:`CMAKE_AUTOUIC` if it is set when a target is created.
+This property is initialized by the value of the
+:variable:`CMAKE_AUTOUIC_OPTIONS` variable if it is set when a target is
+created.
-The options set on the target may be overridden by :prop_sf:`AUTOUIC_OPTIONS` set
-on the ``.ui`` source file.
+The options set on the target may be overridden by :prop_sf:`AUTOUIC_OPTIONS`
+set on the ``.ui`` source file.
This property may use "generator expressions" with the syntax ``$<...>``.
See the :manual:`cmake-generator-expressions(7)` manual for available
expressions.
+
+See the :manual:`cmake-qt(7)` manual for more information on using CMake
+with Qt.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3978473a00bc8a500d8ce406e04aec06ce10a530
commit 3978473a00bc8a500d8ce406e04aec06ce10a530
Author: Stephen Kelly <steveire at gmail.com>
AuthorDate: Mon Feb 3 14:22:01 2014 +0100
Commit: Stephen Kelly <steveire at gmail.com>
CommitDate: Wed Feb 5 15:41:54 2014 +0100
Help: Use ``True`` and ``False`` for IMPORTED values.
Only the first letter is capitalized. It is marked up.
diff --git a/Help/prop_tgt/IMPORTED.rst b/Help/prop_tgt/IMPORTED.rst
index bf9835e..605c1ce 100644
--- a/Help/prop_tgt/IMPORTED.rst
+++ b/Help/prop_tgt/IMPORTED.rst
@@ -3,6 +3,6 @@ IMPORTED
Read-only indication of whether a target is IMPORTED.
-The boolean value of this property is true for targets created with
-the IMPORTED option to add_executable or add_library. It is false for
-targets built within the project.
+The boolean value of this property is ``True`` for targets created with
+the IMPORTED option to :command:`add_executable` or :command:`add_library`.
+It is ``False`` for targets built within the project.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1ab9a085e301f0b278442a2f87cabd15510c6386
commit 1ab9a085e301f0b278442a2f87cabd15510c6386
Author: Stephen Kelly <steveire at gmail.com>
AuthorDate: Wed Feb 5 14:51:08 2014 +0100
Commit: Stephen Kelly <steveire at gmail.com>
CommitDate: Wed Feb 5 15:41:54 2014 +0100
Help: Document relation of properties to the rest of the buildsystem.
diff --git a/Help/prop_dir/COMPILE_DEFINITIONS.rst b/Help/prop_dir/COMPILE_DEFINITIONS.rst
index 290d612..ab7e7f0 100644
--- a/Help/prop_dir/COMPILE_DEFINITIONS.rst
+++ b/Help/prop_dir/COMPILE_DEFINITIONS.rst
@@ -3,18 +3,30 @@ COMPILE_DEFINITIONS
Preprocessor definitions for compiling a directory's sources.
-The COMPILE_DEFINITIONS property may be set to a semicolon-separated
-list of preprocessor definitions using the syntax VAR or VAR=value.
+This property specifies the list of options given so far to the
+:command:`add_definitions` command.
+
+The ``COMPILE_DEFINITIONS`` property may be set to a semicolon-separated
+list of preprocessor definitions using the syntax ``VAR`` or ``VAR=value``.
Function-style definitions are not supported. CMake will
automatically escape the value correctly for the native build system
(note that CMake language syntax may require escapes to specify some
-values). This property may be set on a per-configuration basis using
-the name COMPILE_DEFINITIONS_<CONFIG> where <CONFIG> is an upper-case
-name (ex. "COMPILE_DEFINITIONS_DEBUG"). This property will be
-initialized in each directory by its value in the directory's parent.
+values).
+
+This property will be initialized in each directory by its value in the
+directory's parent.
CMake will automatically drop some definitions that are not supported
by the native build tool. The VS6 IDE does not support definition
values with spaces (but NMake does).
.. include:: /include/COMPILE_DEFINITIONS_DISCLAIMER.txt
+
+Contents of ``COMPILE_DEFINITIONS`` may use "generator expressions" with
+the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
+
+The corresponding :prop_dir:`COMPILE_DEFINITIONS_<CONFIG>` property may
+be set to specify per-configuration definitions. Generator expressions
+should be preferred instead of setting the alternative property.
diff --git a/Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst b/Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst
index 0876ddf..c22606b 100644
--- a/Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst
+++ b/Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst
@@ -3,6 +3,15 @@ COMPILE_DEFINITIONS_<CONFIG>
Per-configuration preprocessor definitions in a directory.
-This is the configuration-specific version of COMPILE_DEFINITIONS.
+This is the configuration-specific version of :prop_dir:`COMPILE_DEFINITIONS`
+where ``<CONFIG>`` is an upper-case name (ex. ``COMPILE_DEFINITIONS_DEBUG``).
+
This property will be initialized in each directory by its value in
the directory's parent.
+
+Contents of ``COMPILE_DEFINITIONS_<CONFIG>`` may use "generator expressions"
+with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
+
+Generator expressions should be preferred instead of setting this property.
diff --git a/Help/prop_dir/COMPILE_OPTIONS.rst b/Help/prop_dir/COMPILE_OPTIONS.rst
index f0c3a42..5953059 100644
--- a/Help/prop_dir/COMPILE_OPTIONS.rst
+++ b/Help/prop_dir/COMPILE_OPTIONS.rst
@@ -3,12 +3,14 @@ COMPILE_OPTIONS
List of options to pass to the compiler.
-This property specifies the list of directories given so far for this
-property. This property exists on directories and targets.
+This property specifies the list of options given so far to the
+:command:`add_compile_options` command.
-The target property values are used by the generators to set the
-options for the compiler.
+This property is used to populate the :prop_tgt:`COMPILE_OPTIONS` target
+property, which is used by the generators to set the options for the
+compiler.
-Contents of COMPILE_OPTIONS may use "generator expressions" with the syntax
-``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual for
-available expressions.
+Contents of ``COMPILE_OPTIONS`` may use "generator expressions" with the
+syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual
+for available expressions. See the :manual:`cmake-buildsystem(7)` manual
+for more on defining buildsystem properties.
diff --git a/Help/prop_dir/INCLUDE_DIRECTORIES.rst b/Help/prop_dir/INCLUDE_DIRECTORIES.rst
index 6c5782f..baba49b 100644
--- a/Help/prop_dir/INCLUDE_DIRECTORIES.rst
+++ b/Help/prop_dir/INCLUDE_DIRECTORIES.rst
@@ -4,15 +4,23 @@ INCLUDE_DIRECTORIES
List of preprocessor include file search directories.
This property specifies the list of directories given so far to the
-include_directories command. This property exists on directories and
-targets. In addition to accepting values from the include_directories
-command, values may be set directly on any directory or any target
-using the set_property command. A target gets its initial value for
-this property from the value of the directory property. A directory
-gets its initial value from its parent directory if it has one. Both
-directory and target property values are adjusted by calls to the
-include_directories command.
+:command:`include_directories` command.
+
+This property is used to populate the :prop_tgt:`INCLUDE_DIRECTORIES`
+target property, which is used by the generators to set the include
+directories for the compiler.
+
+In addition to accepting values from that command, values may be set
+directly on any directory using the :command:`set_property` command. A
+directory gets its initial value from its parent directory if it has one.
+The intial value of the :prop_tgt:`INCLUDE_DIRECTORIES` target property
+comes from the value of this property. Both directory and target property
+values are adjusted by calls to the :command:`include_directories` command.
The target property values are used by the generators to set the
-include paths for the compiler. See also the include_directories
-command.
+include paths for the compiler.
+
+Contents of ``INCLUDE_DIRECTORIES`` may use "generator expressions" with
+the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
diff --git a/Help/prop_tgt/ALIASED_TARGET.rst b/Help/prop_tgt/ALIASED_TARGET.rst
index 0af4365..559c636 100644
--- a/Help/prop_tgt/ALIASED_TARGET.rst
+++ b/Help/prop_tgt/ALIASED_TARGET.rst
@@ -3,5 +3,5 @@ ALIASED_TARGET
Name of target aliased by this target.
-If this is an ALIAS target, this property contains the name of the
+If this is an :ref:`Alias Target`, this property contains the name of the
target aliased.
diff --git a/Help/prop_tgt/COMPATIBLE_INTERFACE_BOOL.rst b/Help/prop_tgt/COMPATIBLE_INTERFACE_BOOL.rst
index 6cf9d0a..6910367 100644
--- a/Help/prop_tgt/COMPATIBLE_INTERFACE_BOOL.rst
+++ b/Help/prop_tgt/COMPATIBLE_INTERFACE_BOOL.rst
@@ -3,17 +3,18 @@ COMPATIBLE_INTERFACE_BOOL
Properties which must be compatible with their link interface
-The COMPATIBLE_INTERFACE_BOOL property may contain a list of
-propertiesfor this target which must be consistent when evaluated as a
-boolean in the INTERFACE of all linked dependees. For example, if a
-property "FOO" appears in the list, then for each dependee, the
-"INTERFACE_FOO" property content in all of its dependencies must be
-consistent with each other, and with the "FOO" property in the
-depender. Consistency in this sense has the meaning that if the
-property is set, then it must have the same boolean value as all
-others, and if the property is not set, then it is ignored. Note that
-for each dependee, the set of properties from this property must not
-intersect with the set of properties from the
-:prop_tgt:`COMPATIBLE_INTERFACE_STRING`,
-:prop_tgt:`COMPATIBLE_INTERFACE_NUMBER_MIN` or
-:prop_tgt:`COMPATIBLE_INTERFACE_NUMBER_MAX` property.
+The ``COMPATIBLE_INTERFACE_BOOL`` property may contain a list of
+properties for this target which must be consistent when evaluated as a
+boolean with the ``INTERFACE`` variant of the property in all linked
+dependees. For example, if a property ``FOO`` appears in the list, then
+for each dependee, the ``INTERFACE_FOO`` property content in all of its
+dependencies must be consistent with each other, and with the ``FOO``
+property in the depender.
+
+Consistency in this sense has the meaning that if the property is set,
+then it must have the same boolean value as all others, and if the
+property is not set, then it is ignored.
+
+Note that for each dependee, the set of properties specified in this
+property must not intersect with the set specified in any of the other
+:ref:`Compatible Interface Properties`.
diff --git a/Help/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MAX.rst b/Help/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MAX.rst
index 2fe748e..298acf1 100644
--- a/Help/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MAX.rst
+++ b/Help/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MAX.rst
@@ -3,15 +3,16 @@ COMPATIBLE_INTERFACE_NUMBER_MAX
Properties whose maximum value from the link interface will be used.
-The COMPATIBLE_INTERFACE_NUMBER_MAX property may contain a list of
-properties for this target whose maximum value may be read at generate time
-when evaluated in the INTERFACE of all linked dependees. For example, if a
-property "FOO" appears in the list, then for each dependee, the
-"INTERFACE_FOO" property content in all of its dependencies will be compared
-with each other and with the "FOO" property in the depender. When reading
-the FOO property at generate time, the maximum value will be returned.
-If the property is not set, then it is ignored. Note that for each
-dependee, the set of properties from this property must not intersect
-with the set of properties from the :prop_tgt:`COMPATIBLE_INTERFACE_BOOL`,
-:prop_tgt:`COMPATIBLE_INTERFACE_STRING` or
-:prop_tgt:`COMPATIBLE_INTERFACE_NUMBER_MIN` property.
+The ``COMPATIBLE_INTERFACE_NUMBER_MAX`` property may contain a list of
+properties for this target whose maximum value may be read at generate
+time when evaluated in the ``INTERFACE`` variant of the property in all
+linked dependees. For example, if a property ``FOO`` appears in the list,
+then for each dependee, the ``INTERFACE_FOO`` property content in all of
+its dependencies will be compared with each other and with the ``FOO``
+property in the depender. When reading the ``FOO`` property at generate
+time, the maximum value will be returned. If the property is not set,
+then it is ignored.
+
+Note that for each dependee, the set of properties specified in this
+property must not intersect with the set specified in any of the other
+:ref:`Compatible Interface Properties`.
diff --git a/Help/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MIN.rst b/Help/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MIN.rst
index 7fe384b..d5fd825 100644
--- a/Help/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MIN.rst
+++ b/Help/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MIN.rst
@@ -3,15 +3,16 @@ COMPATIBLE_INTERFACE_NUMBER_MIN
Properties whose maximum value from the link interface will be used.
-The COMPATIBLE_INTERFACE_NUMBER_MIN property may contain a list of
-properties for this target whose minimum value may be read at generate time
-when evaluated in the INTERFACE of all linked dependees. For example, if a
-property "FOO" appears in the list, then for each dependee, the
-"INTERFACE_FOO" property content in all of its dependencies will be compared
-with each other and with the "FOO" property in the depender. When reading
-the FOO property at generate time, the minimum value will be returned.
-If the property is not set, then it is ignored. Note that for each
-dependee, the set of properties from this property must not intersect
-with the set of properties from the :prop_tgt:`COMPATIBLE_INTERFACE_BOOL`,
-:prop_tgt:`COMPATIBLE_INTERFACE_STRING` or
-:prop_tgt:`COMPATIBLE_INTERFACE_NUMBER_MAX` property.
+The ``COMPATIBLE_INTERFACE_NUMBER_MIN`` property may contain a list of
+properties for this target whose minimum value may be read at generate
+time when evaluated in the ``INTERFACE`` variant of the property of all
+linked dependees. For example, if a
+property ``FOO`` appears in the list, then for each dependee, the
+``INTERFACE_FOO`` property content in all of its dependencies will be
+compared with each other and with the ``FOO`` property in the depender.
+When reading the ``FOO`` property at generate time, the minimum value
+will be returned. If the property is not set, then it is ignored.
+
+Note that for each dependee, the set of properties specified in this
+property must not intersect with the set specified in any of the other
+:ref:`Compatible Interface Properties`.
diff --git a/Help/prop_tgt/COMPATIBLE_INTERFACE_STRING.rst b/Help/prop_tgt/COMPATIBLE_INTERFACE_STRING.rst
index 1794d87..a0050b9 100644
--- a/Help/prop_tgt/COMPATIBLE_INTERFACE_STRING.rst
+++ b/Help/prop_tgt/COMPATIBLE_INTERFACE_STRING.rst
@@ -3,14 +3,14 @@ COMPATIBLE_INTERFACE_STRING
Properties which must be string-compatible with their link interface
-The COMPATIBLE_INTERFACE_STRING property may contain a list of
+The ``COMPATIBLE_INTERFACE_STRING`` property may contain a list of
properties for this target which must be the same when evaluated as a
-string in the INTERFACE of all linked dependees. For example, if a
-property "FOO" appears in the list, then for each dependee, the
-"INTERFACE_FOO" property content in all of its dependencies must be
-equal with each other, and with the "FOO" property in the depender.
-If the property is not set, then it is ignored. Note that for each
-dependee, the set of properties from this property must not intersect
-with the set of properties from the :prop_tgt:`COMPATIBLE_INTERFACE_BOOL`,
-:prop_tgt:`COMPATIBLE_INTERFACE_NUMBER_MIN` or
-:prop_tgt:`COMPATIBLE_INTERFACE_NUMBER_MAX` property.
+string in the ``INTERFACE`` variant of the property all linked dependees.
+For example, if a property ``FOO`` appears in the list, then for each
+dependee, the ``INTERFACE_FOO`` property content in all of its
+dependencies must be equal with each other, and with the ``FOO`` property
+in the depender. If the property is not set, then it is ignored.
+
+Note that for each dependee, the set of properties specified in this
+property must not intersect with the set specified in any of the other
+:ref:`Compatible Interface Properties`.
diff --git a/Help/prop_tgt/COMPILE_DEFINITIONS.rst b/Help/prop_tgt/COMPILE_DEFINITIONS.rst
index 81e73a4..00c49c3 100644
--- a/Help/prop_tgt/COMPILE_DEFINITIONS.rst
+++ b/Help/prop_tgt/COMPILE_DEFINITIONS.rst
@@ -3,21 +3,24 @@ COMPILE_DEFINITIONS
Preprocessor definitions for compiling a target's sources.
-The COMPILE_DEFINITIONS property may be set to a semicolon-separated
-list of preprocessor definitions using the syntax VAR or VAR=value.
+The ``COMPILE_DEFINITIONS`` property may be set to a semicolon-separated
+list of preprocessor definitions using the syntax ``VAR`` or ``VAR=value``.
Function-style definitions are not supported. CMake will
automatically escape the value correctly for the native build system
(note that CMake language syntax may require escapes to specify some
-values). This property may be set on a per-configuration basis using
-the name COMPILE_DEFINITIONS_<CONFIG> where <CONFIG> is an upper-case
-name (ex. "COMPILE_DEFINITIONS_DEBUG").
+values).
CMake will automatically drop some definitions that are not supported
by the native build tool. The VS6 IDE does not support definition
values with spaces (but NMake does).
-Contents of COMPILE_DEFINITIONS may use "generator expressions" with the
+.. include:: /include/COMPILE_DEFINITIONS_DISCLAIMER.txt
+
+Contents of ``COMPILE_DEFINITIONS`` may use "generator expressions" with the
syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual
-for available expressions.
+for available expressions. See the :manual:`cmake-buildsystem(7)` manual
+for more on defining buildsystem properties.
-.. include:: /include/COMPILE_DEFINITIONS_DISCLAIMER.txt
+The corresponding :prop_tgt:`COMPILE_DEFINITIONS_<CONFIG>` property may
+be set to specify per-configuration definitions. Generator expressions
+should be preferred instead of setting the alternative property.
diff --git a/Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst b/Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst
index 0adb7dd..e359d2c 100644
--- a/Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst
+++ b/Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst
@@ -3,4 +3,12 @@ COMPILE_DEFINITIONS_<CONFIG>
Per-configuration preprocessor definitions on a target.
-This is the configuration-specific version of COMPILE_DEFINITIONS.
+This is the configuration-specific version of :prop_tgt:`COMPILE_DEFINITIONS`
+where ``<CONFIG>`` is an upper-case name (ex. ``COMPILE_DEFINITIONS_DEBUG``).
+
+Contents of ``COMPILE_DEFINITIONS_<CONFIG>`` may use "generator expressions"
+with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
+
+Generator expressions should be preferred instead of setting this property.
diff --git a/Help/prop_tgt/COMPILE_OPTIONS.rst b/Help/prop_tgt/COMPILE_OPTIONS.rst
index 9d5c8b9..27cbec1 100644
--- a/Help/prop_tgt/COMPILE_OPTIONS.rst
+++ b/Help/prop_tgt/COMPILE_OPTIONS.rst
@@ -4,11 +4,13 @@ COMPILE_OPTIONS
List of options to pass to the compiler.
This property specifies the list of options specified so far for this
-property. This property exists on directories and targets.
+property.
-The target property values are used by the generators to set the
-options for the compiler.
+This property is intialized by the :prop_dir:`COMPILE_OPTIONS` directory
+property, which is used by the generators to set the options for the
+compiler.
-Contents of COMPILE_OPTIONS may use "generator expressions" with the
-syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual for
-available expressions.
+Contents of ``COMPILE_OPTIONS`` may use "generator expressions" with the
+syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual
+for available expressions. See the :manual:`cmake-buildsystem(7)` manual
+for more on defining buildsystem properties.
diff --git a/Help/prop_tgt/INCLUDE_DIRECTORIES.rst b/Help/prop_tgt/INCLUDE_DIRECTORIES.rst
index 1ab7583..8b40d9c 100644
--- a/Help/prop_tgt/INCLUDE_DIRECTORIES.rst
+++ b/Help/prop_tgt/INCLUDE_DIRECTORIES.rst
@@ -4,22 +4,21 @@ INCLUDE_DIRECTORIES
List of preprocessor include file search directories.
This property specifies the list of directories given so far to the
-include_directories command. This property exists on directories and
-targets. In addition to accepting values from the :command:`include_directories`
-command, values may be set directly on any directory or any target
-using the :command:`set_property` command. A target gets its initial value for
-this property from the value of the directory property. A directory
-gets its initial value from its parent directory if it has one. Both
-directory and target property values are adjusted by calls to the
+:command:`target_include_directories` command. In addition to accepting
+values from that command, values may be set directly on any
+target using the :command:`set_property` command. A target gets its
+initial value for this property from the value of the
+:prop_dir:`INCLUDE_DIRECTORIES` directory property. Both directory and
+target property values are adjusted by calls to the
:command:`include_directories` command.
-The target property values are used by the generators to set the
-include paths for the compiler. See also the :command:`include_directories`
-and :command:`target_include_directories` commands.
+The value of this property is used by the generators to set the include
+paths for the compiler.
Relative paths should not be added to this property directly. Use one of
the commands above instead to handle relative paths.
-Contents of INCLUDE_DIRECTORIES may use "generator expressions" with the
-syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual for
-available expressions.
+Contents of ``INCLUDE_DIRECTORIES`` may use "generator expressions" with
+the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
diff --git a/Help/prop_tgt/INTERFACE_COMPILE_DEFINITIONS.rst b/Help/prop_tgt/INTERFACE_COMPILE_DEFINITIONS.rst
index eb001dd..910b661 100644
--- a/Help/prop_tgt/INTERFACE_COMPILE_DEFINITIONS.rst
+++ b/Help/prop_tgt/INTERFACE_COMPILE_DEFINITIONS.rst
@@ -5,9 +5,11 @@ List of public compile definitions for a library.
Targets may populate this property to publish the compile definitions
required to compile against the headers for the target. Consuming
-targets can add entries to their own COMPILE_DEFINITIONS property such
-as $<TARGET_PROPERTY:foo,INTERFACE_COMPILE_DEFINITIONS> to use the
-compile definitions specified in the interface of 'foo'.
+targets can add entries to their own :prop_tgt:`COMPILE_DEFINITIONS`
+property such as ``$<TARGET_PROPERTY:foo,INTERFACE_COMPILE_DEFINITIONS>``
+to use the compile definitions specified in the interface of ``foo``.
-This property also supports generator expressions. See the
-:manual:`cmake-generator-expressions(7)` manual for available expressions.
+Contents of ``INTERFACE_COMPILE_DEFINITIONS`` may use "generator expressions"
+with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
diff --git a/Help/prop_tgt/INTERFACE_COMPILE_OPTIONS.rst b/Help/prop_tgt/INTERFACE_COMPILE_OPTIONS.rst
index 51b1f6e..d0a38d6 100644
--- a/Help/prop_tgt/INTERFACE_COMPILE_OPTIONS.rst
+++ b/Help/prop_tgt/INTERFACE_COMPILE_OPTIONS.rst
@@ -5,9 +5,11 @@ List of interface options to pass to the compiler.
Targets may populate this property to publish the compile options
required to compile against the headers for the target. Consuming
-targets can add entries to their own COMPILE_OPTIONS property such as
-$<TARGET_PROPERTY:foo,INTERFACE_COMPILE_OPTIONS> to use the compile
-options specified in the interface of 'foo'.
+targets can add entries to their own :prop_tgt:`COMPILE_OPTIONS` property
+such as ``$<TARGET_PROPERTY:foo,INTERFACE_COMPILE_OPTIONS>`` to use the
+compile options specified in the interface of ``foo``.
-This property also supports generator expressions. See the
-:manual:`cmake-generator-expressions(7)` manual for available expressions.
+Contents of ``INTERFACE_COMPILE_OPTIONS`` may use "generator expressions"
+with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
diff --git a/Help/prop_tgt/INTERFACE_INCLUDE_DIRECTORIES.rst b/Help/prop_tgt/INTERFACE_INCLUDE_DIRECTORIES.rst
index 33892da..bf4ab46 100644
--- a/Help/prop_tgt/INTERFACE_INCLUDE_DIRECTORIES.rst
+++ b/Help/prop_tgt/INTERFACE_INCLUDE_DIRECTORIES.rst
@@ -5,9 +5,11 @@ List of public include directories for a library.
Targets may populate this property to publish the include directories
required to compile against the headers for the target. Consuming
-targets can add entries to their own INCLUDE_DIRECTORIES property such
-as $<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES> to use the
-include directories specified in the interface of 'foo'.
+targets can add entries to their own :prop_tgt:`INCLUDE_DIRECTORIES`
+property such as ``$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>``
+to use the include directories specified in the interface of ``foo``.
-This property also supports generator expressions. See the
-:manual:`cmake-generator-expressions(7)` manual for available expressions.
+Contents of ``INTERFACE_INCLUDE_DIRECTORIES`` may use "generator expressions"
+with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
diff --git a/Help/prop_tgt/INTERFACE_LINK_LIBRARIES.rst b/Help/prop_tgt/INTERFACE_LINK_LIBRARIES.rst
index 64ac46e..8e4843b 100644
--- a/Help/prop_tgt/INTERFACE_LINK_LIBRARIES.rst
+++ b/Help/prop_tgt/INTERFACE_LINK_LIBRARIES.rst
@@ -7,8 +7,11 @@ This property contains the list of transitive link dependencies. When
the target is linked into another target the libraries listed (and
recursively their link interface libraries) will be provided to the
other target also. This property is overridden by the
-LINK_INTERFACE_LIBRARIES or LINK_INTERFACE_LIBRARIES_<CONFIG> property
-if policy CMP0022 is OLD or unset.
+:prop_tgt:`LINK_INTERFACE_LIBRARIES` or
+:prop_tgt:`LINK_INTERFACE_LIBRARIES_<CONFIG>` property if policy
+:policy:`CMP0022` is ``OLD`` or unset.
-This property also supports generator expressions. See the
-:manual:`cmake-generator-expressions(7)` manual for available expressions.
+Contents of ``INTERFACE_LINK_LIBRARIES`` may use "generator expressions"
+with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
diff --git a/Help/prop_tgt/INTERFACE_POSITION_INDEPENDENT_CODE.rst b/Help/prop_tgt/INTERFACE_POSITION_INDEPENDENT_CODE.rst
index 76c1e06..ea700df 100644
--- a/Help/prop_tgt/INTERFACE_POSITION_INDEPENDENT_CODE.rst
+++ b/Help/prop_tgt/INTERFACE_POSITION_INDEPENDENT_CODE.rst
@@ -3,13 +3,14 @@ INTERFACE_POSITION_INDEPENDENT_CODE
Whether consumers need to create a position-independent target
-The INTERFACE_POSITION_INDEPENDENT_CODE property informs consumers of
-this target whether they must set their POSITION_INDEPENDENT_CODE
-property to ON. If this property is set to ON, then the
-POSITION_INDEPENDENT_CODE property on all consumers will be set to ON.
-Similarly, if this property is set to OFF, then the
-POSITION_INDEPENDENT_CODE property on all consumers will be set to
-OFF. If this property is undefined, then consumers will determine
-their POSITION_INDEPENDENT_CODE property by other means. Consumers
+The ``INTERFACE_POSITION_INDEPENDENT_CODE`` property informs consumers of
+this target whether they must set their
+:prop_tgt:`POSITION_INDEPENDENT_CODE` property to ``ON``. If this
+property is set to ``ON``, then the :prop_tgt:`POSITION_INDEPENDENT_CODE`
+property on all consumers will be set to ``ON``. Similarly, if this
+property is set to ``OFF``, then the :prop_tgt:`POSITION_INDEPENDENT_CODE`
+property on all consumers will be set to ``OFF``. If this property is
+undefined, then consumers will determine their
+:prop_tgt:`POSITION_INDEPENDENT_CODE` property by other means. Consumers
must ensure that the targets that they link to have a consistent
-requirement for their INTERFACE_POSITION_INDEPENDENT_CODE property.
+requirement for their ``INTERFACE_POSITION_INDEPENDENT_CODE`` property.
diff --git a/Help/prop_tgt/INTERFACE_SYSTEM_INCLUDE_DIRECTORIES.rst b/Help/prop_tgt/INTERFACE_SYSTEM_INCLUDE_DIRECTORIES.rst
index 9a6e3a9..9e603ee 100644
--- a/Help/prop_tgt/INTERFACE_SYSTEM_INCLUDE_DIRECTORIES.rst
+++ b/Help/prop_tgt/INTERFACE_SYSTEM_INCLUDE_DIRECTORIES.rst
@@ -8,5 +8,8 @@ which contain system headers, and therefore should not result in
compiler warnings. Consuming targets will then mark the same include
directories as system headers.
-This property also supports generator expressions. See the
+Contents of ``INTERFACE_SYSTEM_INCLUDE_DIRECTORIES`` may use "generator
+expressions" with the syntax ``$<...>``. See the
:manual:`cmake-generator-expressions(7)` manual for available expressions.
+See the :manual:`cmake-buildsystem(7)` manual for more on defining
+buildsystem properties.
diff --git a/Help/prop_tgt/LINK_LIBRARIES.rst b/Help/prop_tgt/LINK_LIBRARIES.rst
index 48f2830..aa4b9f5 100644
--- a/Help/prop_tgt/LINK_LIBRARIES.rst
+++ b/Help/prop_tgt/LINK_LIBRARIES.rst
@@ -5,13 +5,13 @@ List of direct link dependencies.
This property specifies the list of libraries or targets which will be
used for linking. In addition to accepting values from the
-target_link_libraries command, values may be set directly on any
-target using the set_property command.
+:command:`target_link_libraries` command, values may be set directly on
+any target using the :command:`set_property` command.
-The target property values are used by the generators to set the link
-libraries for the compiler. See also the target_link_libraries
-command.
+The value of this property is used by the generators to set the link
+libraries for the compiler.
-Contents of LINK_LIBRARIES may use "generator expressions" with the syntax
-``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual for
-available expressions.
+Contents of ``LINK_LIBRARIES`` may use "generator expressions" with the
+syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual
+for available expressions. See the :manual:`cmake-buildsystem(7)` manual
+for more on defining buildsystem properties.
diff --git a/Help/prop_tgt/POSITION_INDEPENDENT_CODE.rst b/Help/prop_tgt/POSITION_INDEPENDENT_CODE.rst
index 1202447..54af8c6 100644
--- a/Help/prop_tgt/POSITION_INDEPENDENT_CODE.rst
+++ b/Help/prop_tgt/POSITION_INDEPENDENT_CODE.rst
@@ -3,9 +3,9 @@ POSITION_INDEPENDENT_CODE
Whether to create a position-independent target
-The POSITION_INDEPENDENT_CODE property determines whether position
+The ``POSITION_INDEPENDENT_CODE`` property determines whether position
independent executables or shared libraries will be created. This
-property is true by default for SHARED and MODULE library targets and
-false otherwise. This property is initialized by the value of the
-variable CMAKE_POSITION_INDEPENDENT_CODE if it is set when a target is
-created.
+property is ``True`` by default for ``SHARED`` and ``MODULE`` library
+targets and ``False`` otherwise. This property is initialized by the value
+of the :variable:`CMAKE_POSITION_INDEPENDENT_CODE` variable if it is set
+when a target is created.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fb94fb0bf215e447728c92e0d5997226bd4d8909
commit fb94fb0bf215e447728c92e0d5997226bd4d8909
Author: Stephen Kelly <steveire at gmail.com>
AuthorDate: Mon Feb 3 14:20:42 2014 +0100
Commit: Stephen Kelly <steveire at gmail.com>
CommitDate: Wed Feb 5 15:41:54 2014 +0100
Help: Mark up the buildsystem commands documentation
Cross-link to the cmake-buildsystem manual.
diff --git a/Help/command/add_compile_options.rst b/Help/command/add_compile_options.rst
index 49b38a2..5d71e11 100644
--- a/Help/command/add_compile_options.rst
+++ b/Help/command/add_compile_options.rst
@@ -9,9 +9,14 @@ Adds options to the compilation of source files.
Adds options to the compiler command line for sources in the current
directory and below. This command can be used to add any options, but
-alternative commands exist to add preprocessor definitions or include
-directories. See documentation of the directory and target
-COMPILE_OPTIONS properties for details. Arguments to
-add_compile_options may use "generator expressions" with the syntax
-``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual for
-available expressions.
+alternative commands exist to add preprocessor definitions
+(:command:`target_compile_definitions` and :command:`add_definitions`) or
+include directories (:command:`target_include_directories` and
+:command:`include_directories`). See documentation of the
+:prop_tgt:`directory <COMPILE_OPTIONS>` and
+:prop_tgt:` target <COMPILE_OPTIONS>` ``COMPILE_OPTIONS`` properties.
+
+Arguments to ``add_compile_options`` may use "generator expressions" with
+the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
diff --git a/Help/command/add_definitions.rst b/Help/command/add_definitions.rst
index 4c72752..a9a6bf5 100644
--- a/Help/command/add_definitions.rst
+++ b/Help/command/add_definitions.rst
@@ -7,13 +7,21 @@ Adds -D define flags to the compilation of source files.
add_definitions(-DFOO -DBAR ...)
-Adds flags to the compiler command line for sources in the current
+Adds definitions to the compiler command line for sources in the current
directory and below. This command can be used to add any flags, but
-it was originally intended to add preprocessor definitions. Flags
+it is intended to add preprocessor definitions. Flags
beginning in -D or /D that look like preprocessor definitions are
-automatically added to the COMPILE_DEFINITIONS property for the
-current directory. Definitions with non-trivial values may be left in
-the set of flags instead of being converted for reasons of backwards
-compatibility. See documentation of the directory, target, and source
-file COMPILE_DEFINITIONS properties for details on adding preprocessor
-definitions to specific scopes and configurations.
+automatically added to the :prop_dir:`COMPILE_DEFINITIONS` directory
+property for the current directory. Definitions with non-trivial values
+may be left in the set of flags instead of being converted for reasons of
+backwards compatibility. See documentation of the
+:prop_dir:`directory <COMPILE_DEFINITIONS>`,
+:prop_tgt:`target <COMPILE_DEFINITIONS>`,
+:prop_sf:`source file <COMPILE_DEFINITIONS>` ``COMPILE_DEFINITIONS``
+properties for details on adding preprocessor definitions to specific
+scopes and configurations.
+
+Arguments to ``add_definitions`` may use "generator expressions" with
+the syntax "$<...>". See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
diff --git a/Help/command/add_executable.rst b/Help/command/add_executable.rst
index d6fd929..296adc3 100644
--- a/Help/command/add_executable.rst
+++ b/Help/command/add_executable.rst
@@ -7,67 +7,71 @@ Add an executable to the project using the specified source files.
add_executable(<name> [WIN32] [MACOSX_BUNDLE]
[EXCLUDE_FROM_ALL]
- source1 source2 ... sourceN)
+ source1 [source2 ...])
-Adds an executable target called <name> to be built from the source
-files listed in the command invocation. The <name> corresponds to the
+Adds an executable target called ``<name>`` to be built from the source
+files listed in the command invocation. The ``<name>`` corresponds to the
logical target name and must be globally unique within a project. The
actual file name of the executable built is constructed based on
-conventions of the native platform (such as <name>.exe or just
-<name>).
+conventions of the native platform (such as ``<name>.exe`` or just
+``<name>``.
By default the executable file will be created in the build tree
directory corresponding to the source tree directory in which the
command was invoked. See documentation of the
-RUNTIME_OUTPUT_DIRECTORY target property to change this location. See
-documentation of the OUTPUT_NAME target property to change the <name>
-part of the final file name.
+:prop_tgt:`RUNTIME_OUTPUT_DIRECTORY` target property to change this
+location. See documentation of the :prop_tgt:`OUTPUT_NAME` target property
+to change the ``<name>`` part of the final file name.
-If WIN32 is given the property WIN32_EXECUTABLE will be set on the
-target created. See documentation of that target property for
+If ``WIN32`` is given the property :prop_tgt:`WIN32_EXECUTABLE` will be
+set on the target created. See documentation of that target property for
details.
-If MACOSX_BUNDLE is given the corresponding property will be set on
-the created target. See documentation of the MACOSX_BUNDLE target
-property for details.
+If ``MACOSX_BUNDLE`` is given the corresponding property will be set on
+the created target. See documentation of the :prop_tgt:`MACOSX_BUNDLE`
+target property for details.
-If EXCLUDE_FROM_ALL is given the corresponding property will be set on
-the created target. See documentation of the EXCLUDE_FROM_ALL target
-property for details.
+If ``EXCLUDE_FROM_ALL`` is given the corresponding property will be set on
+the created target. See documentation of the :prop_tgt:`EXCLUDE_FROM_ALL`
+target property for details.
-The add_executable command can also create IMPORTED executable targets
-using this signature:
+See the :manual:`cmake-buildsystem(7)` manual for more on defining
+buildsystem properties.
+
+--------------------------------------------------------------------------
::
add_executable(<name> IMPORTED [GLOBAL])
-An IMPORTED executable target references an executable file located
-outside the project. No rules are generated to build it. The target
-name has scope in the directory in which it is created and below, but
-the GLOBAL option extends visibility. It may be referenced like any
-target built within the project. IMPORTED executables are useful for
-convenient reference from commands like add_custom_command. Details
-about the imported executable are specified by setting properties
+An :ref:`IMPORTED executable target <Imported Target>` references an
+executable file located outside the project. No rules are generated to
+build it, and the :prop_tgt:`IMPORTED` target property is ``True``. The
+target name has scope in the directory in which it is created and below, but
+the ``GLOBAL`` option extends visibility. It may be referenced like any
+target built within the project. ``IMPORTED`` executables are useful
+for convenient reference from commands like :command:`add_custom_command`.
+Details about the imported executable are specified by setting properties
whose names begin in ``IMPORTED_``. The most important such property is
-IMPORTED_LOCATION (and its per-configuration version
-IMPORTED_LOCATION_<CONFIG>) which specifies the location of the main
-executable file on disk. See documentation of the IMPORTED_*
+:prop_tgt:`IMPORTED_LOCATION` (and its per-configuration version
+:prop_tgt:`IMPORTED_LOCATION_<CONFIG>`) which specifies the location of
+the main executable file on disk. See documentation of the ``IMPORTED_*``
properties for more information.
-The signature
+--------------------------------------------------------------------------
::
add_executable(<name> ALIAS <target>)
-creates an alias, such that <name> can be used to refer to <target> in
-subsequent commands. The <name> does not appear in the generated
-buildsystem as a make target. The <target> may not be an IMPORTED
-target or an ALIAS. Alias targets can be used as linkable targets,
-targets to read properties from, executables for custom commands and
-custom targets. They can also be tested for existance with the
-regular if(TARGET) subcommand. The <name> may not be used to modify
-properties of <target>, that is, it may not be used as the operand of
-set_property, set_target_properties, target_link_libraries etc. An
-ALIAS target may not be installed of exported.
+Creates an :ref:`Alias Target`, such that ``<name>`` can
+be used to refer to ``<target>`` in subsequent commands. The ``<name>``
+does not appear in the generated buildsystem as a make target. The
+``<target>`` may not be an :ref:`Imported Target` or an
+``ALIAS``. ``ALIAS`` targets can be used as targets to read properties
+from, executables for custom commands and custom targets. They can also be
+tested for existance with the regular :command:`if(TARGET)` subcommand.
+The ``<name>`` may not be used to modify properties of ``<target>``, that
+is, it may not be used as the operand of :command:`set_property`,
+:command:`set_target_properties`, :command:`target_link_libraries` etc.
+An ``ALIAS`` target may not be installed or exported.
diff --git a/Help/command/add_library.rst b/Help/command/add_library.rst
index 2d69c89..6450485 100644
--- a/Help/command/add_library.rst
+++ b/Help/command/add_library.rst
@@ -7,73 +7,76 @@ Add a library to the project using the specified source files.
add_library(<name> [STATIC | SHARED | MODULE]
[EXCLUDE_FROM_ALL]
- source1 source2 ... sourceN)
+ source1 [source2 ...])
-Adds a library target called <name> to be built from the source files
-listed in the command invocation. The <name> corresponds to the
+Adds a library target called ``<name>`` to be built from the source files
+listed in the command invocation. The ``<name>`` corresponds to the
logical target name and must be globally unique within a project. The
actual file name of the library built is constructed based on
-conventions of the native platform (such as lib<name>.a or
-<name>.lib).
-
-STATIC, SHARED, or MODULE may be given to specify the type of library
-to be created. STATIC libraries are archives of object files for use
-when linking other targets. SHARED libraries are linked dynamically
-and loaded at runtime. MODULE libraries are plugins that are not
-linked into other targets but may be loaded dynamically at runtime
+conventions of the native platform (such as ``lib<name>.a`` or
+``<name>.lib``).
+
+``STATIC``, ``SHARED``, or ``MODULE`` may be given to specify the type of
+library to be created. ``STATIC`` libraries are archives of object files
+for use when linking other targets. ``SHARED`` libraries are linked
+dynamically and loaded at runtime. ``MODULE`` libraries are plugins that
+are not linked into other targets but may be loaded dynamically at runtime
using dlopen-like functionality. If no type is given explicitly the
-type is STATIC or SHARED based on whether the current value of the
-variable BUILD_SHARED_LIBS is true. For SHARED and MODULE libraries
-the POSITION_INDEPENDENT_CODE target property is set to TRUE
-automatically.
-
-By default the library file will be created in the build tree
-directory corresponding to the source tree directory in which the
-command was invoked. See documentation of the
-ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and
-RUNTIME_OUTPUT_DIRECTORY target properties to change this location.
-See documentation of the OUTPUT_NAME target property to change the
-<name> part of the final file name.
-
-If EXCLUDE_FROM_ALL is given the corresponding property will be set on
-the created target. See documentation of the EXCLUDE_FROM_ALL target
-property for details.
-
-The add_library command can also create IMPORTED library targets using
-this signature:
+type is ``STATIC`` or ``SHARED`` based on whether the current value of the
+variable :variable:`BUILD_SHARED_LIBS` is ``ON``. For ``SHARED`` and
+``MODULE`` libraries the :prop_tgt:`POSITION_INDEPENDENT_CODE` target
+property is set to ``ON`` automatically.
+
+By default the library file will be created in the build tree directory
+corresponding to the source tree directory in which thecommand was
+invoked. See documentation of the :prop_tgt:`ARCHIVE_OUTPUT_DIRECTORY`,
+:prop_tgt:`LIBRARY_OUTPUT_DIRECTORY`, and
+:prop_tgt:`RUNTIME_OUTPUT_DIRECTORY` target properties to change this
+location. See documentation of the :prop_tgt:`OUTPUT_NAME` target
+property to change the ``<name>`` part of the final file name.
+
+If ``EXCLUDE_FROM_ALL`` is given the corresponding property will be set on
+the created target. See documentation of the :prop_tgt:`EXCLUDE_FROM_ALL`
+target property for details.
+
+See the :manual:`cmake-buildsystem(7)` manual for more on defining buildsystem
+properties.
+
+--------------------------------------------------------------------------
::
add_library(<name> <SHARED|STATIC|MODULE|UNKNOWN> IMPORTED
[GLOBAL])
-An IMPORTED library target references a library file located outside
-the project. No rules are generated to build it. The target name has
-scope in the directory in which it is created and below, but the
-GLOBAL option extends visibility. It may be referenced like any
-target built within the project. IMPORTED libraries are useful for
-convenient reference from commands like target_link_libraries.
-Details about the imported library are specified by setting properties
-whose names begin in ``IMPORTED_``. The most important such property is
-IMPORTED_LOCATION (and its per-configuration version
-IMPORTED_LOCATION_<CONFIG>) which specifies the location of the main
-library file on disk. See documentation of the IMPORTED_* properties
-for more information.
-
-The signature
+An :ref:`IMPORTED library target <Imported Target>` references a library
+file located outside the project. No rules are generated to build it, and
+the :prop_tgt:`IMPORTED` target property is ``True``. The target name has
+scope in the directory in which it is created and below, but the ``GLOBAL``
+option extends visibility. It may be referenced like any target built
+within the project. ``IMPORTED`` libraries are useful for convenient
+reference from commands like :command:`target_link_libraries`. Details
+about the imported library are specified by setting properties whose names
+begin in ``IMPORTED_`` and ``INTERFACE_``. The most important such
+property is :prop_tgt:`IMPORTED_LOCATION` (and its per-configuration
+variant :prop_tgt:`IMPORTED_LOCATION_<CONFIG>`) which specifies the
+location of the main library file on disk. See documentation of the
+``IMPORTED_*`` and ``INTERFACE_*`` properties for more information.
+
+--------------------------------------------------------------------------
::
add_library(<name> OBJECT <src>...)
-creates a special "object library" target. An object library compiles
+Creates a special "object library" target. An object library compiles
source files but does not archive or link their object files into a
-library. Instead other targets created by add_library or
-add_executable may reference the objects using an expression of the
-form $<TARGET_OBJECTS:objlib> as a source, where "objlib" is the
+library. Instead other targets created by :command:`add_library` or
+:command:`add_executable` may reference the objects using an expression of the
+form ``$<TARGET_OBJECTS:objlib>`` as a source, where ``objlib`` is the
object library name. For example:
-::
+.. code-block:: cmake
add_library(... $<TARGET_OBJECTS:objlib> ...)
add_executable(... $<TARGET_OBJECTS:objlib> ...)
@@ -82,48 +85,51 @@ will include objlib's object files in a library and an executable
along with those compiled from their own sources. Object libraries
may contain only sources (and headers) that compile to object files.
They may contain custom commands generating such sources, but not
-PRE_BUILD, PRE_LINK, or POST_BUILD commands. Object libraries cannot
-be imported, exported, installed, or linked. Some native build
+``PRE_BUILD``, ``PRE_LINK``, or ``POST_BUILD`` commands. Object libraries
+cannot be imported, exported, installed, or linked. Some native build
systems may not like targets that have only object files, so consider
adding at least one real source file to any target that references
-$<TARGET_OBJECTS:objlib>.
+``$<TARGET_OBJECTS:objlib>``.
-The signature
+--------------------------------------------------------------------------
::
add_library(<name> ALIAS <target>)
-creates an alias, such that <name> can be used to refer to <target> in
-subsequent commands. The <name> does not appear in the generated
-buildsystem as a make target. The <target> may not be an IMPORTED
-target or an ALIAS. Alias targets can be used as linkable targets,
-targets to read properties from. They can also be tested for
-existance with the regular if(TARGET) subcommand. The <name> may not
-be used to modify properties of <target>, that is, it may not be used
-as the operand of set_property, set_target_properties,
-target_link_libraries etc. An ALIAS target may not be installed of
-exported.
+Creates an :ref:`Alias Target`, such that ``<name>`` can be
+used to refer to ``<target>`` in subsequent commands. The ``<name>`` does
+not appear in the generatedbuildsystem as a make target. The ``<target>``
+may not be an :ref:`Imported Target` or an ``ALIAS``.
+``ALIAS`` targets can be used as linkable targets and as targets to
+read properties from. They can also be tested for existance with the
+regular :command:`if(TARGET)` subcommand. The ``<name>`` may not be used
+to modify properties of ``<target>``, that is, it may not be used as the
+operand of :command:`set_property`, :command:`set_target_properties`,
+:command:`target_link_libraries` etc. An ``ALIAS`` target may not be
+installed or exported.
-The signature
+--------------------------------------------------------------------------
::
add_library(<name> INTERFACE [IMPORTED [GLOBAL]])
-creates an interface target. An interface target does not directly
-create build output, though it may have properties set on it and it
-may be installed, exported and imported. Typically the INTERFACE_*
-properties are populated on the interface target using the
-:command:`set_property`, :command:`target_link_libraries`,
-:command:`target_include_directories`
-and :command:`target_compile_defintions` commands, and then it is used as an
-argument to :command:`target_link_libraries` like any other target.
-
-An ``INTERFACE`` :prop_tgt:`IMPORTED` target may also be created with this
-signature. An :prop_tgt:`IMPORTED` library target references a library defined
-outside the project. The target name has scope in the directory in which it is
-created and below, but the ``GLOBAL`` option extends visibility. It may be
-referenced like any target built within the project. :prop_tgt:`IMPORTED`
+Creates an :ref:`Interface Library`. An ``INTERFACE`` library target does
+not directly create build output, though it may have properties set on it
+and it may be installed, exported and imported. Typically the
+``INTERFACE_*`` properties are populated on the interface target using the
+:command:`set_property`, :command:`target_link_libraries(INTERFACE)`,
+:command:`target_include_directories(INTERFACE)`,
+:command:`target_compile_options(INTERFACE)`
+and :command:`target_compile_definitions(INTERFACE)` commands, and then it
+is used as an argument to :command:`target_link_libraries` like any other
+target.
+
+An ``INTERFACE`` :ref:`Imported Target` may also be created with this
+signature. An ``IMPORTED`` library target references a library defined
+outside the project. The target name has scope in the directory in which
+it is created and below, but the ``GLOBAL`` option extends visibility. It
+may be referenced like any target built within the project. ``IMPORTED``
libraries are useful for convenient reference from commands like
:command:`target_link_libraries`.
diff --git a/Help/command/include_directories.rst b/Help/command/include_directories.rst
index 3e0c7a0..f694934 100644
--- a/Help/command/include_directories.rst
+++ b/Help/command/include_directories.rst
@@ -5,26 +5,31 @@ Add include directories to the build.
::
- include_directories([AFTER|BEFORE] [SYSTEM] dir1 dir2 ...)
+ include_directories([AFTER|BEFORE] [SYSTEM] dir1 [dir2 ...])
Add the given directories to those the compiler uses to search for
include files. Relative paths are interpreted as relative to the
current source directory.
-The include directories are added to the directory property
-INCLUDE_DIRECTORIES for the current CMakeLists file. They are also
-added to the target property INCLUDE_DIRECTORIES for each target in
-the current CMakeLists file. The target property values are the ones
-used by the generators.
+The include directories are added to the :prop_dir:`INCLUDE_DIRECTORIES`
+directory property for the current ``CMakeLists`` file. They are also
+added to the :prop_tgt:`INCLUDE_DIRECTORIES` target property for each
+target in the current ``CMakeLists`` file. The target property values
+are the ones used by the generators.
-By default the directories are appended onto the current list of
+By default the directories specified are appended onto the current list of
directories. This default behavior can be changed by setting
-:variable:`CMAKE_INCLUDE_DIRECTORIES_BEFORE` to ON. By using AFTER or BEFORE
-explicitly, you can select between appending and prepending,
-independent of the default.
+:variable:`CMAKE_INCLUDE_DIRECTORIES_BEFORE` to ``ON``. By using
+``AFTER`` or ``BEFORE`` explicitly, you can select between appending and
+prepending, independent of the default.
-If the SYSTEM option is given, the compiler will be told the
-directories are meant as system include directories on some platforms
-(signalling this setting might achieve effects such as the compiler
+If the ``SYSTEM`` option is given, the compiler will be told the
+directories are meant as system include directories on some platforms.
+Signalling this setting might achieve effects such as the compiler
skipping warnings, or these fixed-install system files not being
-considered in dependency calculations - see compiler docs).
+considered in dependency calculations - see compiler docs.
+
+Arguments to ``include_directories`` may use "generator expressions" with
+the syntax "$<...>". See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
diff --git a/Help/command/target_compile_definitions.rst b/Help/command/target_compile_definitions.rst
index d32cc18..0a4219e 100644
--- a/Help/command/target_compile_definitions.rst
+++ b/Help/command/target_compile_definitions.rst
@@ -5,20 +5,24 @@ Add compile definitions to a target.
::
- target_compile_definitions(<target> <INTERFACE|PUBLIC|PRIVATE> [items1...]
+ target_compile_definitions(<target>
+ <INTERFACE|PUBLIC|PRIVATE> [items1...]
[<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])
-Specify compile definitions to use when compiling a given target. The
-named <target> must have been created by a command such as
-add_executable or add_library and must not be an IMPORTED target. The
-INTERFACE, PUBLIC and PRIVATE keywords are required to specify the
-scope of the following arguments. PRIVATE and PUBLIC items will
-populate the COMPILE_DEFINITIONS property of <target>. PUBLIC and
-INTERFACE items will populate the INTERFACE_COMPILE_DEFINITIONS
-property of <target>. The following arguments specify compile
-definitions. Repeated calls for the same <target> append items in the
-order called.
+Specify compile definitions to use when compiling a given <target. The
+named ``<target>`` must have been created by a command such as
+:command:`add_executable` or :command:`add_library` and must not be an
+:ref:`Imported Target`.
-Arguments to target_compile_definitions may use "generator expressions" with
-the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual
-for available expressions.
+The ``INTERFACE``, ``PUBLIC`` and ``PRIVATE`` keywords are required to
+specify the scope of the following arguments. ``PRIVATE`` and ``PUBLIC``
+items will populate the :prop_tgt:`COMPILE_DEFINITIONS` property of
+``<target>``. ``PUBLIC`` and ``INTERFACE`` items will populate the
+:prop_tgt:`INTERFACE_COMPILE_DEFINITIONS` property of ``<target>``. The
+following arguments specify compile definitions. Repeated calls for the
+same ``<target>`` append items in the order called.
+
+Arguments to ``target_compile_definitions`` may use "generator expressions"
+with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
diff --git a/Help/command/target_compile_options.rst b/Help/command/target_compile_options.rst
index 3870abf..eb1d874 100644
--- a/Help/command/target_compile_options.rst
+++ b/Help/command/target_compile_options.rst
@@ -5,23 +5,25 @@ Add compile options to a target.
::
- target_compile_options(<target> [BEFORE] <INTERFACE|PUBLIC|PRIVATE> [items1...]
+ target_compile_options(<target> [BEFORE]
+ <INTERFACE|PUBLIC|PRIVATE> [items1...]
[<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])
Specify compile options to use when compiling a given target. The
-named <target> must have been created by a command such as
-add_executable or add_library and must not be an IMPORTED target. If
-BEFORE is specified, the content will be prepended to the property
-instead of being appended.
+named ``<target>`` must have been created by a command such as
+:command:`add_executable` or :command:`add_library` and must not be an
+:prop_tgt:`IMPORTED Target`. If ``BEFORE`` is specified, the content will
+be prepended to the property instead of being appended.
-The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the
-scope of the following arguments. PRIVATE and PUBLIC items will
-populate the COMPILE_OPTIONS property of <target>. PUBLIC and
-INTERFACE items will populate the INTERFACE_COMPILE_OPTIONS property
-of <target>. The following arguments specify compile options.
-Repeated calls for the same <target> append items in the order called.
+The ``INTERFACE``, ``PUBLIC`` and ``PRIVATE`` keywords are required to
+specify the scope of the following arguments. ``PRIVATE`` and ``PUBLIC``
+items will populate the :prop_tgt:`COMPILE_OPTIONS` property of
+``<target>``. ``PUBLIC`` and ``INTERFACE`` items will populate the
+:prop_tgt:`INTERFACE_COMPILE_OPTIONS` property of ``<target>``. The
+following arguments specify compile options. Repeated calls for the same
+``<target>`` append items in the order called.
-Arguments to target_compile_options may use "generator expressions"
-with the syntax ``$<...>``.
-See the :manual:`cmake-generator-expressions(7)` manual for available
-expressions.
+Arguments to ``target_compile_options`` may use "generator expressions"
+with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
diff --git a/Help/command/target_include_directories.rst b/Help/command/target_include_directories.rst
index 2fd7d7f..75f917d 100644
--- a/Help/command/target_include_directories.rst
+++ b/Help/command/target_include_directories.rst
@@ -5,33 +5,38 @@ Add include directories to a target.
::
- target_include_directories(<target> [SYSTEM] [BEFORE] <INTERFACE|PUBLIC|PRIVATE> [items1...]
+ target_include_directories(<target> [SYSTEM] [BEFORE]
+ <INTERFACE|PUBLIC|PRIVATE> [items1...]
[<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])
Specify include directories or targets to use when compiling a given
-target. The named <target> must have been created by a command such
-as add_executable or add_library and must not be an IMPORTED target.
+target. The named ``<target>`` must have been created by a command such
+as :command:`add_executable` or :command:`add_library` and must not be an
+:prop_tgt:`IMPORTED` target.
-If BEFORE is specified, the content will be prepended to the property
+If ``BEFORE`` is specified, the content will be prepended to the property
instead of being appended.
-The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the
-scope of the following arguments. PRIVATE and PUBLIC items will
-populate the INCLUDE_DIRECTORIES property of <target>. PUBLIC and
-INTERFACE items will populate the INTERFACE_INCLUDE_DIRECTORIES
-property of <target>. The following arguments specify include
-directories. Specified include directories may be absolute paths or
-relative paths. Repeated calls for the same <target> append items in
-the order called.If SYSTEM is specified, the compiler will be told the
+The ``INTERFACE``, ``PUBLIC`` and ``PRIVATE`` keywords are required to specify
+the scope of the following arguments. ``PRIVATE`` and ``PUBLIC`` items will
+populate the :prop_tgt:`INCLUDE_DIRECTORIES` property of ``<target>``.
+``PUBLIC`` and ``INTERFACE`` items will populate the
+:prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES`
+property of ``<target>``. The following arguments specify include
+directories.
+
+Specified include directories may be absolute paths or relative paths.
+Repeated calls for the same <target> append items in the order called. If
+``SYSTEM`` is specified, the compiler will be told the
directories are meant as system include directories on some platforms
(signalling this setting might achieve effects such as the compiler
skipping warnings, or these fixed-install system files not being
-considered in dependency calculations - see compiler docs). If SYSTEM
-is used together with PUBLIC or INTERFACE, the
-INTERFACE_SYSTEM_INCLUDE_DIRECTORIES target property will be populated
-with the specified directories.
-
-Arguments to target_include_directories may use "generator
-expressions" with the syntax ``$<...>``.
-See the :manual:`cmake-generator-expressions(7)` manual for available
-expressions.
+considered in dependency calculations - see compiler docs). If ``SYSTEM``
+is used together with ``PUBLIC`` or ``INTERFACE``, the
+:prop_tgt:`INTERFACE_SYSTEM_INCLUDE_DIRECTORIES` target property will be
+populated with the specified directories.
+
+Arguments to ``target_include_directories`` may use "generator expressions"
+with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
+manual for available expressions. See the :manual:`cmake-buildsystem(7)`
+manual for more on defining buildsystem properties.
diff --git a/Help/command/target_link_libraries.rst b/Help/command/target_link_libraries.rst
index eaecf21..ef50e0a 100644
--- a/Help/command/target_link_libraries.rst
+++ b/Help/command/target_link_libraries.rst
@@ -9,60 +9,49 @@ Link a target to given libraries.
[[debug|optimized|general] <item>] ...)
Specify libraries or flags to use when linking a given target. The
-named <target> must have been created in the current directory by a
-command such as add_executable or add_library. The remaining
-arguments specify library names or flags. Repeated calls for the same
-<target> append items in the order called.
+named ``<target>`` must have been created in the current directory by a
+command such as :command:`add_executable` or :command:`add_library`. The
+remaining arguments specify library names or flags. Repeated calls for
+the same ``<target>`` append items in the order called.
If a library name matches that of another target in the project a
-dependency will automatically be added in the build system to make
-sure the library being linked is up-to-date before the target links.
-Item names starting with '-', but not '-l' or '-framework', are
-treated as linker flags.
+dependency will automatically be added in the build system to make sure
+the library being linked is up-to-date before the target links. Item names
+starting with ``-``, but not ``-l`` or ``-framework``, are treated as
+linker flags.
-A "debug", "optimized", or "general" keyword indicates that the
+A ``debug``, ``optimized``, or ``general`` keyword indicates that the
library immediately following it is to be used only for the
-corresponding build configuration. The "debug" keyword corresponds to
+corresponding build configuration. The ``debug`` keyword corresponds to
the Debug configuration (or to configurations named in the
-DEBUG_CONFIGURATIONS global property if it is set). The "optimized"
-keyword corresponds to all other configurations. The "general"
-keyword corresponds to all configurations, and is purely optional
-(assumed if omitted). Higher granularity may be achieved for
-per-configuration rules by creating and linking to IMPORTED library
-targets. See the IMPORTED mode of the add_library command for more
-information.
+:prop_gbl:`DEBUG_CONFIGURATIONS` global property if it is set). The
+``optimized`` keyword corresponds to all other configurations. The
+``general`` keyword corresponds to all configurations, and is purely
+optional (assumed if omitted). Higher granularity may be achieved for
+per-configuration rules by creating and linking to
+:ref:`IMPORTED library targets <Imported Target>`.
Library dependencies are transitive by default with this signature.
When this target is linked into another target then the libraries
linked to this target will appear on the link line for the other
target too. This transitive "link interface" is stored in the
-INTERFACE_LINK_LIBRARIES target property when policy CMP0022 is set to
-NEW and may be overridden by setting the property directly.
-(When CMP0022 is not set to NEW, transitive linking is builtin but may
-be overridden by the LINK_INTERFACE_LIBRARIES property. Calls to other
-signatures of this command may set the property making any libraries
-linked exclusively by this signature private.)
-
-CMake will also propagate "usage requirements" from linked library
-targets. Usage requirements affect compilation of sources in the
-<target>. They are specified by properties defined on linked targets.
-During generation of the build system, CMake integrates usage
-requirement property values with the corresponding build properties
-for <target>:
-
-::
-
- INTERFACE_COMPILE_DEFINITONS: Appends to COMPILE_DEFINITONS
- INTERFACE_INCLUDE_DIRECTORIES: Appends to INCLUDE_DIRECTORIES
- INTERFACE_POSITION_INDEPENDENT_CODE: Sets POSITION_INDEPENDENT_CODE
- or checked for consistency with existing value
+:prop_tgt:`INTERFACE_LINK_LIBRARIES` target property and may be overridden
+by setting the property directly. When :policy:`CMP0022` is not set to
+``NEW``, transitive linking is built in but may be overridden by the
+:prop_tgt:`LINK_INTERFACE_LIBRARIES` property. Calls to other signatures
+of this command may set the property making any libraries linked
+exclusively by this signature private.
+CMake will also propagate :ref:`usage requirements <Target Usage Requirements>`
+from linked library targets. Usage requirements of dependencies affect
+compilation of sources in the ``<target>``.
+If an ``<item>`` is a library in a Mac OX framework, the ``Headers``
+directory of the framework will also be processed as a
+:ref:`usage requirement <Target Usage Requirements>`. This has the same
+effect as passing the framework directory as an include directory.
-If an <item> is a library in a Mac OX framework, the Headers directory
-of the framework will also be processed as a "usage requirement".
-This has the same effect as passing the framework directory as an
-include directory.
+--------------------------------------------------------------------------
::
@@ -70,34 +59,44 @@ include directory.
<PRIVATE|PUBLIC|INTERFACE> <lib> ...
[<PRIVATE|PUBLIC|INTERFACE> <lib> ... ] ...])
-The PUBLIC, PRIVATE and INTERFACE keywords can be used to specify both
-the link dependencies and the link interface in one command.
-Libraries and targets following PUBLIC are linked to, and are made
-part of the link interface. Libraries and targets following PRIVATE
+The ``PUBLIC``, ``PRIVATE`` and ``INTERFACE`` keywords can be used to
+specify both the link dependencies and the link interface in one command.
+Libraries and targets following ``PUBLIC`` are linked to, and are made
+part of the link interface. Libraries and targets following ``PRIVATE``
are linked to, but are not made part of the link interface. Libraries
-following INTERFACE are appended to the link interface and are not
-used for linking <target>.
+following ``INTERFACE`` are appended to the link interface and are not
+used for linking ``<target>``.
+
+--------------------------------------------------------------------------
::
target_link_libraries(<target> LINK_INTERFACE_LIBRARIES
[[debug|optimized|general] <lib>] ...)
-The LINK_INTERFACE_LIBRARIES mode appends the libraries to the
-INTERFACE_LINK_LIBRARIES target property instead of using them for
-linking. If policy CMP0022 is not NEW, then this mode also appends
-libraries to the LINK_INTERFACE_LIBRARIES and its per-configuration
-equivalent. This signature is for compatibility only. Prefer the
-INTERFACE mode instead. Libraries specified as "debug" are wrapped in
-a generator expression to correspond to debug builds. If policy
-CMP0022 is not NEW, the libraries are also appended to the
-LINK_INTERFACE_LIBRARIES_DEBUG property (or to the properties
-corresponding to configurations listed in the DEBUG_CONFIGURATIONS
-global property if it is set). Libraries specified as "optimized" are
-appended to the INTERFACE_LINK_LIBRARIES property. If policy CMP0022
-is not NEW, they are also appended to the LINK_INTERFACE_LIBRARIES
-property. Libraries specified as "general" (or without any keyword)
-are treated as if specified for both "debug" and "optimized".
+The ``LINK_INTERFACE_LIBRARIES`` mode appends the libraries to the
+:prop_tgt:`INTERFACE_LINK_LIBRARIES` target property instead of using them
+for linking. If policy :policy:`CMP0022` is not ``NEW``, then this mode
+also appends libraries to the :prop_tgt:`LINK_INTERFACE_LIBRARIES` and its
+per-configuration equivalent.
+
+This signature is for compatibility only. Prefer the ``INTERFACE`` mode
+instead.
+
+Libraries specified as ``debug`` are wrapped in a generator expression to
+correspond to debug builds. If policy :policy:`CMP0022` is
+not ``NEW``, the libraries are also appended to the
+:prop_tgt:`LINK_INTERFACE_LIBRARIES_DEBUG <LINK_INTERFACE_LIBRARIES_<CONFIG>>`
+property (or to the properties corresponding to configurations listed in
+the :prop_gbl:`DEBUG_CONFIGURATIONS` global property if it is set).
+Libraries specified as ``optimized`` are appended to the
+:prop_tgt:`INTERFACE_LINK_LIBRARIES` property. If policy :policy:`CMP0022`
+is not ``NEW``, they are also appended to the
+:prop_tgt:`LINK_INTERFACE_LIBRARIES` property. Libraries specified as
+``general`` (or without any keyword) are treated as if specified for both
+``debug`` and ``optimized``.
+
+--------------------------------------------------------------------------
::
@@ -107,23 +106,26 @@ are treated as if specified for both "debug" and "optimized".
[<LINK_PRIVATE|LINK_PUBLIC>
[[debug|optimized|general] <lib>] ...])
-The LINK_PUBLIC and LINK_PRIVATE modes can be used to specify both the
-link dependencies and the link interface in one command. This
-signature is for compatibility only. Prefer the PUBLIC or PRIVATE
-keywords instead. Libraries and targets following LINK_PUBLIC are
-linked to, and are made part of the INTERFACE_LINK_LIBRARIES. If
-policy CMP0022 is not NEW, they are also made part of the
-LINK_INTERFACE_LIBRARIES. Libraries and targets following
-LINK_PRIVATE are linked to, but are not made part of the
-INTERFACE_LINK_LIBRARIES (or LINK_INTERFACE_LIBRARIES).
-
-The library dependency graph is normally acyclic (a DAG), but in the
-case of mutually-dependent STATIC libraries CMake allows the graph to
-contain cycles (strongly connected components). When another target
-links to one of the libraries CMake repeats the entire connected
-component. For example, the code
+The ``LINK_PUBLIC`` and ``LINK_PRIVATE`` modes can be used to specify both
+the link dependencies and the link interface in one command.
-::
+This signature is for compatibility only. Prefer the ``PUBLIC`` or
+``PRIVATE`` keywords instead.
+
+Libraries and targets following ``LINK_PUBLIC`` are linked to, and are
+made part of the :prop_tgt:`INTERFACE_LINK_LIBRARIES`. If policy
+:policy:`CMP0022` is not ``NEW``, they are also made part of the
+:prop_tgt:`LINK_INTERFACE_LIBRARIES`. Libraries and targets following
+``LINK_PRIVATE`` are linked to, but are not made part of the
+:prop_tgt:`INTERFACE_LINK_LIBRARIES` (or :prop_tgt:`LINK_INTERFACE_LIBRARIES`).
+
+The library dependency graph is normally acyclic (a DAG), but in the case
+of mutually-dependent ``STATIC`` libraries CMake allows the graph to
+contain cycles (strongly connected components). When another target links
+to one of the libraries, CMake repeats the entire connected component.
+For example, the code
+
+.. code-block:: cmake
add_library(A STATIC a.c)
add_library(B STATIC b.c)
@@ -132,15 +134,16 @@ component. For example, the code
add_executable(main main.c)
target_link_libraries(main A)
-links 'main' to 'A B A B'. (While one repetition is usually
-sufficient, pathological object file and symbol arrangements can
-require more. One may handle such cases by manually repeating the
-component in the last target_link_libraries call. However, if two
-archives are really so interdependent they should probably be combined
-into a single archive.)
+links ``main`` to ``A B A B``. While one repetition is usually
+sufficient, pathological object file and symbol arrangements can require
+more. One may handle such cases by manually repeating the component in
+the last ``target_link_libraries`` call. However, if two archives are
+really so interdependent they should probably be combined into a single
+archive.
Arguments to target_link_libraries may use "generator expressions"
with the syntax ``$<...>``. Note however, that generator expressions
-will not be used in OLD handling of CMP0003 or CMP0004.
+will not be used in OLD handling of :policy:`CMP0003` or :policy:`CMP0004`.
See the :manual:`cmake-generator-expressions(7)` manual for available
-expressions.
+expressions. See the :manual:`cmake-buildsystem(7)` manual for more on
+defining buildsystem properties.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ff6661d4abe197e89cb3be0e707cc7e16abb7a39
commit ff6661d4abe197e89cb3be0e707cc7e16abb7a39
Author: Stephen Kelly <steveire at gmail.com>
AuthorDate: Wed Feb 5 14:51:01 2014 +0100
Commit: Stephen Kelly <steveire at gmail.com>
CommitDate: Wed Feb 5 15:41:54 2014 +0100
Help: Note that the compatible interface properties must not intersect.
diff --git a/Help/manual/cmake-buildsystem.7.rst b/Help/manual/cmake-buildsystem.7.rst
index 54795ce..0424d81 100644
--- a/Help/manual/cmake-buildsystem.7.rst
+++ b/Help/manual/cmake-buildsystem.7.rst
@@ -380,6 +380,10 @@ calculate the numeric minimum value for a property from dependencies.
Each calculated "compatible" property value may be read in the consumer at
generate-time using generator expressions.
+Note that for each dependee, the set of properties specified in each
+compatible interface property must not intersect with the set specified in
+any of the other properties.
+
Property Origin Debugging
-------------------------
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad2e8e7ceda0004183ff230ca6fa590f4e826dc2
commit ad2e8e7ceda0004183ff230ca6fa590f4e826dc2
Author: Stephen Kelly <steveire at gmail.com>
AuthorDate: Wed Feb 5 13:59:17 2014 +0100
Commit: Stephen Kelly <steveire at gmail.com>
CommitDate: Wed Feb 5 15:41:54 2014 +0100
Help: Specify how to order and modify transitively set property values.
diff --git a/Help/manual/cmake-buildsystem.7.rst b/Help/manual/cmake-buildsystem.7.rst
index 6dcd0cd..54795ce 100644
--- a/Help/manual/cmake-buildsystem.7.rst
+++ b/Help/manual/cmake-buildsystem.7.rst
@@ -178,7 +178,7 @@ Transitive Usage Requirements
-----------------------------
The usage requirements of a target can transitively propagate to dependents.
-The :command:`target_link_libraries` command also has ``PRIVATE``,
+The :command:`target_link_libraries` command has ``PRIVATE``,
``INTERFACE`` and ``PUBLIC`` keywords to control the propagation.
.. code-block:: cmake
@@ -221,6 +221,26 @@ each keyword:
PRIVATE serialization
)
+Usage requirements are propagated by reading the ``INTERFACE_`` variants
+of target properties from dependencies and appending the values to the
+non-``INTERFACE_`` variants of the operand. For example, the
+:prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` of dependencies is read and
+appended to the :prop_tgt:`INCLUDE_DIRECTORIES` of the operand. In cases
+where order is relevant and maintained, and the order resulting from the
+:command:`target_link_libraries` calls does not allow correct compilation,
+use of an appropriate command to set the property directly may update the
+order.
+
+For example, if the linked libraries for a target must be specified
+in the order ``lib1`` ``lib2`` ``lib3`` , but the include directories must
+be specified in the order ``lib3`` ``lib1`` ``lib2``:
+
+.. code-block:: cmake
+
+ target_link_libraries(myExe lib1 lib2 lib3)
+ target_include_directories(myExe
+ PRIVATE $<TARGET_PROPERTY:INTERFACE_INCLUDE_DIRECTORIES:lib3>)
+
.. _`Compatible Interface Properties`:
Compatible Interface Properties
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f1c86097f4411309ffb9da08758e2ca3909f9f95
commit f1c86097f4411309ffb9da08758e2ca3909f9f95
Author: Stephen Kelly <steveire at gmail.com>
AuthorDate: Mon Feb 3 14:17:23 2014 +0100
Commit: Stephen Kelly <steveire at gmail.com>
CommitDate: Wed Feb 5 15:41:54 2014 +0100
Help: Add references to manual sections.
These can be refered to from the command documentation and other
relevant locations.
diff --git a/Help/manual/cmake-buildsystem.7.rst b/Help/manual/cmake-buildsystem.7.rst
index 8a21adf..6dcd0cd 100644
--- a/Help/manual/cmake-buildsystem.7.rst
+++ b/Help/manual/cmake-buildsystem.7.rst
@@ -171,6 +171,9 @@ can be enabled to add the corresponding directories to the
targets in multiple different directories convenient through use of the
:command:`target_link_libraries` command.
+
+.. _`Target Usage Requirements`:
+
Transitive Usage Requirements
-----------------------------
@@ -641,6 +644,8 @@ Some target types do not represent outputs of the buildsystem, but only inputs
such as external dependencies, aliases or other non-build artifacts. Pseudo
targets are not represented in the generated buildsystem.
+.. _`Imported Target`:
+
Imported Targets
----------------
@@ -677,6 +682,8 @@ accessible globally in the buildsystem.
See the :manual:`cmake-packages(7)` manual for more on creating packages
with :prop_tgt:`IMPORTED` targets.
+.. _`Alias Target`:
+
Alias Targets
-------------
@@ -718,6 +725,8 @@ property from it:
message(STATUS "The name Upstream::lib1 is an ALIAS for ${_aliased}.")
endif()
+.. _`Interface Library`:
+
Interface Libraries
-------------------
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7b5c5c67f447eafeb9c0af251a103e4577c4c8b3
commit 7b5c5c67f447eafeb9c0af251a103e4577c4c8b3
Author: Stephen Kelly <steveire at gmail.com>
AuthorDate: Wed Feb 5 13:19:02 2014 +0100
Commit: Stephen Kelly <steveire at gmail.com>
CommitDate: Wed Feb 5 15:41:54 2014 +0100
Help: Use ``inline-literals`` to mark generator expressions.
diff --git a/Help/command/add_compile_options.rst b/Help/command/add_compile_options.rst
index a9329f4..49b38a2 100644
--- a/Help/command/add_compile_options.rst
+++ b/Help/command/add_compile_options.rst
@@ -13,5 +13,5 @@ alternative commands exist to add preprocessor definitions or include
directories. See documentation of the directory and target
COMPILE_OPTIONS properties for details. Arguments to
add_compile_options may use "generator expressions" with the syntax
-"$<...>". See the :manual:`cmake-generator-expressions(7)` manual for
+``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual for
available expressions.
diff --git a/Help/command/add_custom_command.rst b/Help/command/add_custom_command.rst
index 4de708f..b0c5446 100644
--- a/Help/command/add_custom_command.rst
+++ b/Help/command/add_custom_command.rst
@@ -113,7 +113,7 @@ dependency that would cause the custom command to re-run whenever the
executable is recompiled.
Arguments to COMMAND may use "generator expressions" with the syntax
-"$<...>". See the :manual:`cmake-generator-expressions(7)` manual for
+``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual for
available expressions.
Note that tgt is not added as a dependency of the target this
diff --git a/Help/command/add_test.rst b/Help/command/add_test.rst
index 7363d5f..5714559 100644
--- a/Help/command/add_test.rst
+++ b/Help/command/add_test.rst
@@ -35,7 +35,7 @@ a WORKING_DIRECTORY option is given then the test will be executed in
the given directory.
Arguments after COMMAND may use "generator expressions" with the syntax
-"$<...>". See the :manual:`cmake-generator-expressions(7)` manual for
+``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual for
available expressions.
Note that tgt is not added as a dependency of the target this
diff --git a/Help/command/target_compile_definitions.rst b/Help/command/target_compile_definitions.rst
index 5c223a2..d32cc18 100644
--- a/Help/command/target_compile_definitions.rst
+++ b/Help/command/target_compile_definitions.rst
@@ -20,5 +20,5 @@ definitions. Repeated calls for the same <target> append items in the
order called.
Arguments to target_compile_definitions may use "generator expressions" with
-the syntax "$<...>". See the :manual:`cmake-generator-expressions(7)` manual
+the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual
for available expressions.
diff --git a/Help/command/target_compile_options.rst b/Help/command/target_compile_options.rst
index 71d57f9..3870abf 100644
--- a/Help/command/target_compile_options.rst
+++ b/Help/command/target_compile_options.rst
@@ -22,6 +22,6 @@ of <target>. The following arguments specify compile options.
Repeated calls for the same <target> append items in the order called.
Arguments to target_compile_options may use "generator expressions"
-with the syntax "$<...>".
+with the syntax ``$<...>``.
See the :manual:`cmake-generator-expressions(7)` manual for available
expressions.
diff --git a/Help/command/target_include_directories.rst b/Help/command/target_include_directories.rst
index 4835b96..2fd7d7f 100644
--- a/Help/command/target_include_directories.rst
+++ b/Help/command/target_include_directories.rst
@@ -32,6 +32,6 @@ INTERFACE_SYSTEM_INCLUDE_DIRECTORIES target property will be populated
with the specified directories.
Arguments to target_include_directories may use "generator
-expressions" with the syntax "$<...>".
+expressions" with the syntax ``$<...>``.
See the :manual:`cmake-generator-expressions(7)` manual for available
expressions.
diff --git a/Help/command/target_link_libraries.rst b/Help/command/target_link_libraries.rst
index c2d2dc6..eaecf21 100644
--- a/Help/command/target_link_libraries.rst
+++ b/Help/command/target_link_libraries.rst
@@ -140,7 +140,7 @@ archives are really so interdependent they should probably be combined
into a single archive.)
Arguments to target_link_libraries may use "generator expressions"
-with the syntax "$<...>". Note however, that generator expressions
+with the syntax ``$<...>``. Note however, that generator expressions
will not be used in OLD handling of CMP0003 or CMP0004.
See the :manual:`cmake-generator-expressions(7)` manual for available
expressions.
diff --git a/Help/prop_dir/COMPILE_OPTIONS.rst b/Help/prop_dir/COMPILE_OPTIONS.rst
index e8d1b8a..f0c3a42 100644
--- a/Help/prop_dir/COMPILE_OPTIONS.rst
+++ b/Help/prop_dir/COMPILE_OPTIONS.rst
@@ -10,5 +10,5 @@ The target property values are used by the generators to set the
options for the compiler.
Contents of COMPILE_OPTIONS may use "generator expressions" with the syntax
-"$<...>". See the :manual:`cmake-generator-expressions(7)` manual for
+``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual for
available expressions.
diff --git a/Help/prop_tgt/AUTOUIC_OPTIONS.rst b/Help/prop_tgt/AUTOUIC_OPTIONS.rst
index d0f865c..2571634 100644
--- a/Help/prop_tgt/AUTOUIC_OPTIONS.rst
+++ b/Help/prop_tgt/AUTOUIC_OPTIONS.rst
@@ -16,6 +16,6 @@ This property is initialized by the value of the variable
The options set on the target may be overridden by :prop_sf:`AUTOUIC_OPTIONS` set
on the ``.ui`` source file.
-This property may use "generator expressions" with the syntax "$<...>".
+This property may use "generator expressions" with the syntax ``$<...>``.
See the :manual:`cmake-generator-expressions(7)` manual for available
expressions.
diff --git a/Help/prop_tgt/COMPILE_DEFINITIONS.rst b/Help/prop_tgt/COMPILE_DEFINITIONS.rst
index 51bdb92..81e73a4 100644
--- a/Help/prop_tgt/COMPILE_DEFINITIONS.rst
+++ b/Help/prop_tgt/COMPILE_DEFINITIONS.rst
@@ -17,7 +17,7 @@ by the native build tool. The VS6 IDE does not support definition
values with spaces (but NMake does).
Contents of COMPILE_DEFINITIONS may use "generator expressions" with the
-syntax "$<...>". See the :manual:`cmake-generator-expressions(7)` manual
+syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual
for available expressions.
.. include:: /include/COMPILE_DEFINITIONS_DISCLAIMER.txt
diff --git a/Help/prop_tgt/COMPILE_OPTIONS.rst b/Help/prop_tgt/COMPILE_OPTIONS.rst
index 80e0ccb..9d5c8b9 100644
--- a/Help/prop_tgt/COMPILE_OPTIONS.rst
+++ b/Help/prop_tgt/COMPILE_OPTIONS.rst
@@ -10,5 +10,5 @@ The target property values are used by the generators to set the
options for the compiler.
Contents of COMPILE_OPTIONS may use "generator expressions" with the
-syntax "$<...>". See the :manual:`cmake-generator-expressions(7)` manual for
+syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual for
available expressions.
diff --git a/Help/prop_tgt/INCLUDE_DIRECTORIES.rst b/Help/prop_tgt/INCLUDE_DIRECTORIES.rst
index cf358b3..1ab7583 100644
--- a/Help/prop_tgt/INCLUDE_DIRECTORIES.rst
+++ b/Help/prop_tgt/INCLUDE_DIRECTORIES.rst
@@ -21,5 +21,5 @@ Relative paths should not be added to this property directly. Use one of
the commands above instead to handle relative paths.
Contents of INCLUDE_DIRECTORIES may use "generator expressions" with the
-syntax "$<...>". See the :manual:`cmake-generator-expressions(7)` manual for
+syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual for
available expressions.
diff --git a/Help/prop_tgt/LINK_LIBRARIES.rst b/Help/prop_tgt/LINK_LIBRARIES.rst
index b18fe30..48f2830 100644
--- a/Help/prop_tgt/LINK_LIBRARIES.rst
+++ b/Help/prop_tgt/LINK_LIBRARIES.rst
@@ -13,5 +13,5 @@ libraries for the compiler. See also the target_link_libraries
command.
Contents of LINK_LIBRARIES may use "generator expressions" with the syntax
-"$<...>". See the :manual:`cmake-generator-expressions(7)` manual for
+``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual for
available expressions.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cf059f54aef337a7e0528a756e0df114709c09f4
commit cf059f54aef337a7e0528a756e0df114709c09f4
Author: Stephen Kelly <steveire at gmail.com>
AuthorDate: Mon Feb 3 14:16:49 2014 +0100
Commit: Stephen Kelly <steveire at gmail.com>
CommitDate: Wed Feb 5 15:41:54 2014 +0100
Help: Mark up references to NEW and OLD policy settings properly.
diff --git a/Help/manual/cmake-policies.7.rst b/Help/manual/cmake-policies.7.rst
index 5a9ec95..972a9f8 100644
--- a/Help/manual/cmake-policies.7.rst
+++ b/Help/manual/cmake-policies.7.rst
@@ -15,15 +15,15 @@ across multiple releases. When a new policy is introduced, newer CMake
versions will begin to warn about the backward compatible behavior. It
is possible to disable the warning by explicitly requesting the OLD, or
backward compatible behavior using the :command:`cmake_policy` command.
-It is also possible to request NEW, or non-backward compatible behavior
+It is also possible to request ``NEW``, or non-backward compatible behavior
for a policy, also avoiding the warning. Each policy can also be set to
-either NEW or OLD behavior explicitly on the command line with the
+either ``NEW`` or ``OLD`` behavior explicitly on the command line with the
:variable:`CMAKE_POLICY_DEFAULT_CMP<NNNN>` variable.
The :command:`cmake_minimum_required` command does more than report an
error if a too-old version of CMake is used to build a project. It
also sets all policies introduced in that CMake version or earlier to
-NEW behavior. To manage policies without increasing the minimum required
+``NEW`` behavior. To manage policies without increasing the minimum required
CMake version, the :command:`if(POLICY)` command may be used:
.. code-block:: cmake
@@ -32,7 +32,7 @@ CMake version, the :command:`if(POLICY)` command may be used:
cmake_policy(SET CMP0990 NEW)
endif()
-This has the effect of using the NEW behavior with newer CMake releases which
+This has the effect of using the ``NEW`` behavior with newer CMake releases which
users may be using and not issuing a compatibility warning.
The setting of a policy is confined in some cases to not propagate to the
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f99a9a7b17db365520513822538311a340821d3
commit 7f99a9a7b17db365520513822538311a340821d3
Author: Stephen Kelly <steveire at gmail.com>
AuthorDate: Mon Feb 3 14:16:08 2014 +0100
Commit: Stephen Kelly <steveire at gmail.com>
CommitDate: Wed Feb 5 15:41:54 2014 +0100
Help: Add a style guide.
diff --git a/Help/manual/cmake-developer.7.rst b/Help/manual/cmake-developer.7.rst
index b1d413e..3a80dca 100644
--- a/Help/manual/cmake-developer.7.rst
+++ b/Help/manual/cmake-developer.7.rst
@@ -207,6 +207,170 @@ processed by `Sphinx`_ to generate the CMake help manuals.
.. _`reStructuredText`: http://docutils.sourceforge.net/docs/ref/rst/introduction.html
.. _`Sphinx`: http://sphinx-doc.org
+Style
+-----
+
+1)
+ Command signatures should be marked up as plain literal blocks, not as
+ cmake ``code-blocks``.
+
+2)
+ Signatures are separated from preceding content by a horizontal
+ line. That is, use:
+
+ .. code-block:: rst
+
+ ... preceding paragraph.
+
+ ---------------------------------------------------------------------
+
+ ::
+
+ add_library(<lib> ...)
+
+ This signature is used for ...
+
+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.
+
+4)
+ Use two spaces for indentation. Use two spaces between sentences in
+ prose.
+
+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.
+
+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.
+
+7)
+ Mark up self-references with ``inline-literal`` syntax. For example,
+ within the add_executable command documentation, use
+
+ .. code-block:: rst
+
+ ``add_executable``
+
+ not
+
+ .. code-block:: rst
+
+ :command:`add_executable`
+
+ which is used elsewhere.
+
+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.
+
+9)
+ Mark up references to keywords in signatures, file names, and other
+ technical terms with ``inline-literl`` syntax, for example:
+
+ .. code-block:: rst
+
+ 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.
+
+
+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:
+
+ .. code-block:: rst
+
+ This command creates an :ref:`Imported Target`.
+
+ instead of:
+
+ .. code-block:: rst
+
+ This command creates an :prop_tgt:`IMPORTED` target.
+
+ The latter should be used only when referring specifically to the
+ property.
+
+ References to manual sections are not automatically created by creating
+ a section, but code such as:
+
+ .. code-block:: rst
+
+ .. _`Imported Targets`:
+
+ creates a suitable anchor.
+
+ 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 Target`).
+
+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.
+
+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
+
+ Title Text
+ ----------
+
+ Capitalize the first letter of each non-minor word in the title.
+
+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:
+
+ .. code-block:: rst
+
+ Set the :prop_tgt:`AUTOMOC` target property to ``ON``.
+
+ Instead of
+
+ .. code-block:: rst
+
+ 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:
+
+ .. code-block:: rst
+
+ If policy :prop_tgt:`CMP0022` is set to ``NEW`` the behavior is ...
+
+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.
+
+15)
+ Use American English spellings in prose.
+
+
Markup Constructs
-----------------
@@ -249,8 +413,7 @@ literal block after ``::``
the following indented block as literal text without interpretation.
The command-line help processor prints the ``::`` literally and
prints the block content with common indentation replaced by one
- space. We prefer the ``::`` to appear at the end of a paragraph
- line instead of as its own line.
+ space.
``note`` directive
Call out a side note. The command-line help processor prints the
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=13fd94ae6d59009d208e272349cdacb42441105d
commit 13fd94ae6d59009d208e272349cdacb42441105d
Author: Stephen Kelly <steveire at gmail.com>
AuthorDate: Tue Feb 4 17:27:51 2014 +0100
Commit: Stephen Kelly <steveire at gmail.com>
CommitDate: Wed Feb 5 15:41:54 2014 +0100
Help: Fix typos
Psuedo -> Pseudo
behaviour -> behavior
CMake uses American spelling.
diff --git a/Help/manual/cmake-buildsystem.7.rst b/Help/manual/cmake-buildsystem.7.rst
index 2b37c0c..8a21adf 100644
--- a/Help/manual/cmake-buildsystem.7.rst
+++ b/Help/manual/cmake-buildsystem.7.rst
@@ -634,7 +634,7 @@ target at a time. The commands :command:`add_definitions`,
a similar function, but operate at directory scope instead of target
scope for convenience.
-Psuedo Targets
+Pseudo Targets
==============
Some target types do not represent outputs of the buildsystem, but only inputs
diff --git a/Help/manual/cmake-developer.7.rst b/Help/manual/cmake-developer.7.rst
index d169e1a..b1d413e 100644
--- a/Help/manual/cmake-developer.7.rst
+++ b/Help/manual/cmake-developer.7.rst
@@ -703,7 +703,7 @@ If the package provides Xxx_INCLUDE_DIRS and Xxx_LIBRARIES variables, the
include dirs and libraries for all components which were requested and which
have been found should be added to those two variables.
-To get this behaviour you can use the FIND_PACKAGE_HANDLE_STANDARD_ARGS()
+To get this behavior you can use the FIND_PACKAGE_HANDLE_STANDARD_ARGS()
macro, as an example see FindJPEG.cmake.
For internal implementation, it's a generally accepted convention that
-----------------------------------------------------------------------
Summary of changes:
Help/command/add_compile_options.rst | 17 +-
Help/command/add_custom_command.rst | 2 +-
Help/command/add_definitions.rst | 24 ++-
Help/command/add_executable.rst | 82 ++++-----
Help/command/add_library.rst | 162 +++++++++---------
Help/command/add_test.rst | 2 +-
Help/command/include_directories.rst | 33 ++--
Help/command/target_compile_definitions.rst | 32 ++--
Help/command/target_compile_options.rst | 32 ++--
Help/command/target_include_directories.rst | 47 +++---
Help/command/target_link_libraries.rst | 177 ++++++++++----------
Help/manual/cmake-buildsystem.7.rst | 37 +++-
Help/manual/cmake-developer.7.rst | 169 ++++++++++++++++++-
Help/manual/cmake-policies.7.rst | 8 +-
Help/prop_dir/COMPILE_DEFINITIONS.rst | 24 ++-
Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst | 11 +-
Help/prop_dir/COMPILE_OPTIONS.rst | 16 +-
Help/prop_dir/INCLUDE_DIRECTORIES.rst | 28 ++--
Help/prop_tgt/ALIASED_TARGET.rst | 2 +-
Help/prop_tgt/AUTOGEN_TARGET_DEPENDS.rst | 5 +-
Help/prop_tgt/AUTOMOC.rst | 13 +-
Help/prop_tgt/AUTOMOC_MOC_OPTIONS.rst | 13 +-
Help/prop_tgt/AUTORCC.rst | 14 +-
Help/prop_tgt/AUTORCC_OPTIONS.rst | 16 +-
Help/prop_tgt/AUTOUIC.rst | 18 +-
Help/prop_tgt/AUTOUIC_OPTIONS.rst | 20 ++-
Help/prop_tgt/COMPATIBLE_INTERFACE_BOOL.rst | 29 ++--
Help/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MAX.rst | 25 +--
Help/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MIN.rst | 25 +--
Help/prop_tgt/COMPATIBLE_INTERFACE_STRING.rst | 20 +--
Help/prop_tgt/COMPILE_DEFINITIONS.rst | 21 ++-
Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst | 10 +-
Help/prop_tgt/COMPILE_OPTIONS.rst | 14 +-
Help/prop_tgt/IMPORTED.rst | 6 +-
Help/prop_tgt/INCLUDE_DIRECTORIES.rst | 25 ++-
Help/prop_tgt/INTERFACE_COMPILE_DEFINITIONS.rst | 12 +-
Help/prop_tgt/INTERFACE_COMPILE_OPTIONS.rst | 12 +-
Help/prop_tgt/INTERFACE_INCLUDE_DIRECTORIES.rst | 12 +-
Help/prop_tgt/INTERFACE_LINK_LIBRARIES.rst | 11 +-
.../INTERFACE_POSITION_INDEPENDENT_CODE.rst | 19 ++-
.../INTERFACE_SYSTEM_INCLUDE_DIRECTORIES.rst | 5 +-
Help/prop_tgt/LINK_LIBRARIES.rst | 16 +-
Help/prop_tgt/POSITION_INDEPENDENT_CODE.rst | 10 +-
43 files changed, 797 insertions(+), 479 deletions(-)
hooks/post-receive
--
CMake
More information about the Cmake-commits
mailing list