Commit 456e0fb6 authored by Bartosz Kosiorek's avatar Bartosz Kosiorek

Help: Improve documentation formating

parent 5ad73b60
......@@ -9,7 +9,7 @@ Get a global property of the CMake instance.
Gets a global property from the CMake instance. The value of
the ``<property>`` is stored in the variable ``<var>``.
If the property is not found, ``<var>`` will be set to ``"NOTFOUND"``.
If the property is not found, ``<var>`` will be set to ``NOTFOUND``.
See the :manual:`cmake-properties(7)` manual for available properties.
See also the :command:`get_property` command ``GLOBAL`` option.
......
......@@ -11,7 +11,7 @@ Get a property from a target. The value of the property is stored in
the variable ``VAR``. If the target property is not found, the behavior
depends on whether it has been defined to be an ``INHERITED`` property
or not (see :command:`define_property`). Non-inherited properties will
set ``VAR`` to "NOTFOUND", whereas inherited properties will search the
set ``VAR`` to ``NOTFOUND``, whereas inherited properties will search the
relevant parent scope as described for the :command:`define_property`
command and if still unable to find the property, ``VAR`` will be set to
an empty string.
......
......@@ -227,7 +227,7 @@ above. The result is ``OFF`` which is false. However, if we remove the
if(var2)
which is true because ``var2`` is defined to "var1" which is not a false
which is true because ``var2`` is defined to ``var1`` which is not a false
constant.
Automatic evaluation applies in the other cases whenever the
......
......@@ -13,7 +13,7 @@ Include an external Microsoft project file in a workspace.
Includes an external Microsoft project in the generated workspace
file. Currently does nothing on UNIX. This will create a target
named [projectname]. This can be used in the :command:`add_dependencies`
named ``[projectname]``. This can be used in the :command:`add_dependencies`
command to make things depend on the external project.
``TYPE``, ``GUID`` and ``PLATFORM`` are optional parameters that allow one to
......
......@@ -21,7 +21,7 @@ or its corresponding location in the binary tree may be listed. If a
file specified already has an extension, that extension will be
removed first. This is useful for providing lists of source files
such as foo.cxx when you want the corresponding foo.h to be installed.
A typical extension is '.h'.
A typical extension is ``.h``.
::
......
......@@ -16,7 +16,7 @@ Supported operators are ``+``, ``-``, ``*``, ``/``, ``%``, ``|``, ``&``,
``^``, ``~``, ``<<``, ``>>``, and ``(...)``; they have the same meaning
as in C code.
Hexadecimal numbers are recognized when prefixed with "0x", as in C code.
Hexadecimal numbers are recognized when prefixed with ``0x``, as in C code.
The result is formatted according to the option ``OUTPUT_FORMAT``,
where ``<format>`` is one of
......
......@@ -14,6 +14,6 @@ more advanced scanner.
output_required_files(srcfile outputfile)
Outputs a list of all the source files that are required by the
specified srcfile. This list is written into outputfile. This is
similar to writing out the dependencies for srcfile except that it
jumps from .h files into .cxx, .c and .cpp files if possible.
specified ``srcfile``. This list is written into ``outputfile``. This is
similar to writing out the dependencies for ``srcfile`` except that it
jumps from ``.h`` files into ``.cxx``, ``.c`` and ``.cpp`` files if possible.
......@@ -57,7 +57,7 @@ Each ``<item>`` may be:
as when a shared library is detected to have no ``SONAME`` field.
See policy :policy:`CMP0060` for discussion of another case.
If the library file is in a Mac OSX framework, the ``Headers`` directory
If the library file is in a macOS 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.
......
......@@ -12,26 +12,27 @@ Bundle-specific parameters (``CPACK_BUNDLE_xxx``).
.. variable:: CPACK_BUNDLE_NAME
The name of the generated bundle. This appears in the OSX finder as the
The name of the generated bundle. This appears in the macOS Finder as the
bundle name. Required.
.. variable:: CPACK_BUNDLE_PLIST
Path to an OSX plist file that will be used for the generated bundle. This
assumes that the caller has generated or specified their own Info.plist
Path to an macOS Property List (``.plist``) file that will be used
for the generated bundle. This
assumes that the caller has generated or specified their own ``Info.plist``
file. Required.
.. variable:: CPACK_BUNDLE_ICON
Path to an OSX icon file that will be used as the icon for the generated
bundle. This is the icon that appears in the OSX finder for the bundle, and
in the OSX dock when the bundle is opened. Required.
Path to an macOS icon file that will be used as the icon for the generated
bundle. This is the icon that appears in the macOS Finder for the bundle, and
in the macOS dock when the bundle is opened. Required.
.. variable:: CPACK_BUNDLE_STARTUP_COMMAND
Path to a startup script. This is a path to an executable or script that
will be run whenever an end-user double-clicks the generated bundle in the
OSX Finder. Optional.
macOS Finder. Optional.
.. variable:: CPACK_BUNDLE_APPLE_CERT_APP
......@@ -42,8 +43,9 @@ Bundle-specific parameters (``CPACK_BUNDLE_xxx``).
.. variable:: CPACK_BUNDLE_APPLE_ENTITLEMENTS
The name of the ``Plist`` file that contains your apple entitlements for sandboxing
your application. This file is required for submission to the Mac App Store.
The name of the Property List (``.plist``) file that contains your Apple
entitlements for sandboxing your application. This file is required
for submission to the macOS App Store.
.. variable:: CPACK_BUNDLE_APPLE_CODESIGN_FILES
......
......@@ -13,7 +13,7 @@ provided by CPack, such as component installation and the dependency graph.
Integration with External Packaging Tools
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The CPack External generator generates a .json file containing the
The CPack External generator generates a ``.json`` file containing the
CPack internal metadata, which gives external software information
on how to package the software. External packaging software may itself
invoke CPack, consume the generated metadata,
......
......@@ -22,19 +22,19 @@ http://www.rpm.org/wiki/Docs
.. note::
`<COMPONENT>` part of variables is preferred to be in upper case (for e.g. if
component is named `foo` then use `CPACK_RPM_FOO_XXXX` variable name format)
as is with other `CPACK_<COMPONENT>_XXXX` variables.
`<COMPONENT>` part of variables is preferred to be in upper case (e.g. if
component is named ``foo`` then use ``CPACK_RPM_FOO_XXXX`` variable name format)
as is with other ``CPACK_<COMPONENT>_XXXX`` variables.
For the purposes of back compatibility (CMake/CPack version 3.5 and lower)
support for same cased component (e.g. `fOo` would be used as
`CPACK_RPM_fOo_XXXX`) is still supported for variables defined in older
support for same cased component (e.g. ``fOo`` would be used as
``CPACK_RPM_fOo_XXXX``) is still supported for variables defined in older
versions of CMake/CPack but is not guaranteed for variables that
will be added in the future. For the sake of back compatibility same cased
component variables also override upper cased versions where both are
present.
Here are some CPack RPM generator wiki resources that are here for historic reasons and
are no longer maintained but may still prove useful:
Here are some CPack RPM generator wiki resources that are here for historic
reasons and are no longer maintained but may still prove useful:
- https://gitlab.kitware.com/cmake/community/wikis/doc/cpack/Configuration
- https://gitlab.kitware.com/cmake/community/wikis/doc/cpack/PackageGenerators#rpm-unix-only
......@@ -48,8 +48,8 @@ List of CPack RPM generator specific variables:
* Mandatory : NO
* Default : OFF
If enabled (ON) multiple packages are generated. By default a single package
containing files of all components is generated.
If enabled (``ON``) multiple packages are generated. By default
a single package containing files of all components is generated.
.. variable:: CPACK_RPM_PACKAGE_SUMMARY
CPACK_RPM_<component>_PACKAGE_SUMMARY
......@@ -76,14 +76,14 @@ List of CPack RPM generator specific variables:
* Default : ``<CPACK_PACKAGE_FILE_NAME>[-<component>].rpm`` with spaces
replaced by '-'
This may be set to ``RPM-DEFAULT`` to allow rpmbuild tool to generate package
This may be set to ``RPM-DEFAULT`` to allow ``rpmbuild`` tool to generate package
file name by itself.
Alternatively provided package file name must end with ``.rpm`` suffix.
.. note::
By using user provided spec file, rpm macro extensions such as for
generating debuginfo packages or by simply using multiple components more
generating ``debuginfo`` packages or by simply using multiple components more
than one rpm file may be generated, either from a single spec file or from
multiple spec files (each component execution produces its own spec file).
In such cases duplicate file names may occur as a result of this variable
......@@ -127,7 +127,7 @@ List of CPack RPM generator specific variables:
* Mandatory : YES
* Default : Native architecture output by ``uname -m``
This may be set to ``noarch`` if you know you are building a noarch package.
This may be set to ``noarch`` if you know you are building a ``noarch`` package.
.. variable:: CPACK_RPM_PACKAGE_RELEASE
......@@ -207,7 +207,7 @@ List of CPack RPM generator specific variables:
* Default : -
May be used to override RPM compression type to be used to build the
RPM. For example some Linux distribution now default to lzma or xz
RPM. For example some Linux distribution now default to ``lzma`` or ``xz``
compression whereas older cannot use such RPM. Using this one can enforce
compression type to be used.
......@@ -226,8 +226,8 @@ List of CPack RPM generator specific variables:
* Mandatory : NO
* Default : -
May be used to enable (1, yes) or disable (0, no) automatic shared libraries
dependency detection. Dependencies are added to requires list.
May be used to enable (``1``, ``yes``) or disable (``0``, ``no``) automatic
shared libraries dependency detection. Dependencies are added to requires list.
.. note::
......@@ -241,9 +241,9 @@ List of CPack RPM generator specific variables:
* Mandatory : NO
* Default : -
May be used to enable (1, yes) or disable (0, no) automatic listing of shared
libraries that are provided by the package. Shared libraries are added to
provides list.
May be used to enable (``1``, ``yes``) or disable (``0``, ``no``)
automatic listing of shared libraries that are provided by the package.
Shared libraries are added to provides list.
.. note::
......@@ -258,8 +258,8 @@ List of CPack RPM generator specific variables:
* Default : -
Variable enables/disables autoreq and autoprov at the same time.
See :variable:`CPACK_RPM_PACKAGE_AUTOREQ` and :variable:`CPACK_RPM_PACKAGE_AUTOPROV`
for more details.
See :variable:`CPACK_RPM_PACKAGE_AUTOREQ` and
:variable:`CPACK_RPM_PACKAGE_AUTOPROV` for more details.
.. note::
......
......@@ -4,14 +4,14 @@ CodeBlocks
Generates CodeBlocks project files.
Project files for CodeBlocks will be created in the top directory and
in every subdirectory which features a CMakeLists.txt file containing
a PROJECT() call. Additionally a hierarchy of makefiles is generated
in every subdirectory which features a ``CMakeLists.txt`` file containing
a :command:`project` call. Additionally a hierarchy of makefiles is generated
into the build tree.
The :variable:`CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES` variable may
be set to ``ON`` to exclude any files which are located outside of
the project root directory.
The appropriate make program can build the
project through the default make target. A "make install" target is
project through the default ``all`` target. An ``install`` target is
also provided.
This "extra" generator may be specified as:
......
......@@ -7,11 +7,11 @@ Project files for CodeLite will be created in the top directory and
in every subdirectory which features a CMakeLists.txt file containing
a :command:`project` call.
The :variable:`CMAKE_CODELITE_USE_TARGETS` variable may be set to ``ON``
to change the default behaviour from projects to targets as the basis
to change the default behavior from projects to targets as the basis
for project files.
The appropriate make program can build the
project through the default make target. A "make install" target is
also provided.
project through the default ``all`` target. An ``install`` target
is also provided.
This "extra" generator may be specified as:
......
......@@ -7,7 +7,7 @@ Project files for Eclipse will be created in the top directory. In
out of source builds, a linked resource to the top level source
directory will be created. Additionally a hierarchy of makefiles is
generated into the build tree. The appropriate make program can build
the project through the default make target. A "make install" target
the project through the default ``all`` target. An ``install`` target
is also provided.
This "extra" generator may be specified as:
......
......@@ -9,8 +9,9 @@ via the :variable:`CMAKE_BUILD_TYPE` variable.
Customizations that are used to pick toolset and target system:
The ``-A <arch>`` can be supplied for setting the target architecture.
``<arch>`` usually is one of "arm", "ppc", "86", etcetera. If the target architecture
is not specified then the default architecture of "arm" will be used.
``<arch>`` usually is one of ``arm``, ``ppc``, ``86``, etcetera.
If the target architecture is not specified then
the default architecture of ``arm`` will be used.
The ``-T <toolset>`` option can be used to set the directory location of the toolset.
Both absolute and relative paths are valid. Relative paths use ``GHS_TOOLSET_ROOT``
......
......@@ -5,10 +5,10 @@ Generates Kate project files.
A project file for Kate will be created in the top directory in the top level
build directory.
To use it in kate, the Project plugin must be enabled.
The project file is loaded in kate simply by opening the
ProjectName.kateproject file in the editor.
If the kate Build-plugin is enabled, all targets generated by CMake are
To use it in Kate, the Project plugin must be enabled.
The project file is loaded in Kate by opening the
``ProjectName.kateproject`` file in the editor.
If the Kate Build-plugin is enabled, all targets generated by CMake are
available for building.
This "extra" generator may be specified as:
......
MSYS Makefiles
--------------
Generates makefiles for use with MSYS ``make`` under the MSYS shell.
Generates makefiles for use with MSYS (Minimal SYStem)
``make`` under the MSYS shell.
Use this generator in a MSYS shell prompt and using ``make`` as the build
tool. The generated makefiles use ``/bin/sh`` as the shell to launch build
......
......@@ -4,7 +4,8 @@ MinGW Makefiles
Generates makefiles for use with ``mingw32-make`` under a Windows command
prompt.
Use this generator under a Windows command prompt with MinGW in the ``PATH``
Use this generator under a Windows command prompt with
MinGW (Minimalist GNU for Windows) in the ``PATH``
and using ``mingw32-make`` as the build tool. The generated makefiles use
``cmd.exe`` as the shell to launch build rules. They are not compatible with
MSYS or a unix shell.
......
......@@ -4,8 +4,8 @@ Ninja
Generates build.ninja files.
A build.ninja file is generated into the build tree. Recent versions
of the ninja program can build the project through the "all" target.
An "install" target is also provided.
of the ninja program can build the project through the ``all`` target.
An ``install`` target is also provided.
For each subdirectory ``sub/dir`` of the project, additional targets
are generated:
......
......@@ -4,11 +4,11 @@ Sublime Text 2
Generates Sublime Text 2 project files.
Project files for Sublime Text 2 will be created in the top directory
and in every subdirectory which features a CMakeLists.txt file
containing a PROJECT() call. Additionally Makefiles (or build.ninja
files) are generated into the build tree. The appropriate make
program can build the project through the default make target. A
"make install" target is also provided.
and in every subdirectory which features a ``CMakeLists.txt`` file
containing a :command:`project` call. Additionally ``Makefiles``
(or ``build.ninja`` files) are generated into the build tree.
The appropriate make program can build the project through the default ``all``
target. An ``install`` target is also provided.
This "extra" generator may be specified as:
......
......@@ -5,4 +5,4 @@ Generates standard UNIX makefiles.
A hierarchy of UNIX makefiles is generated into the build tree. Any
standard UNIX-style make program can build the project through the
default make target. A "make install" target is also provided.
default ``all`` target. An ``install`` target is also provided.
For each toolset that comes with this version of Visual Studio, there are
variants that are themselves compiled for 32-bit (x86) and 64-bit (x64) hosts
(independent of the architecture they target).
variants that are themselves compiled for 32-bit (``x86``) and
64-bit (``x64``) hosts (independent of the architecture they target).
|VS_TOOLSET_HOST_ARCH_DEFAULT|
One may explicitly request use of either the 32-bit or 64-bit host tools
by adding either ``host=x86`` or ``host=x64`` to the toolset specification.
......
CPackWIX
--------
The documentation for the CPack WIX generator has moved here: :cpack_gen:`CPack WIX Generator`
The documentation for the CPack WIX generator has moved here:
:cpack_gen:`CPack WIX Generator`
......@@ -12,11 +12,12 @@ In CMake 2.4 and below it is possible to write code like
where ``somelib`` is supposed to be a valid library file name such as
``libsomelib.a`` or ``somelib.lib``. For Makefile generators this
produces an error at build time because the dependency on the full
path cannot be found. For VS IDE and Xcode generators this used to
path cannot be found. For :ref:`Visual Studio Generators` IDE
and :generator:`Xcode` generators this used to
work by accident because CMake would always split off the library
directory and ask the linker to search for the library by name
(``-lsomelib`` or ``somelib.lib``). Despite the failure with Makefiles, some
projects have code like this and build only with VS and/or Xcode.
projects have code like this and build only with Visual Studio and/or Xcode.
This version of CMake prefers to pass the full path directly to the
native build tool, which will fail in this case because it does not
name a valid library file.
......
......@@ -4,11 +4,11 @@ CMP0014
Input directories must have ``CMakeLists.txt``.
CMake versions before 2.8 silently ignored missing ``CMakeLists.txt``
files in directories referenced by add_subdirectory() or subdirs(),
files in directories referenced by :command:`add_subdirectory` or :command:`subdirs`,
treating them as if present but empty. In CMake 2.8.0 and above this
policy determines whether or not the case is an error. The ``OLD``
behavior for this policy is to silently ignore the problem. The ``NEW``
behavior for this policy is to report an error.
:command:`cmake_policy` determines whether or not the case is an error.
The ``OLD`` behavior for this policy is to silently ignore the problem.
The ``NEW`` behavior for this policy is to report an error.
This policy was introduced in CMake version 2.8.0. CMake version
|release| warns when the policy is not set and uses ``OLD`` behavior. Use
......
CMP0015
-------
link_directories() treats paths relative to the source dir.
:command:`link_directories` treats paths relative to the source dir.
In CMake 2.8.0 and lower the link_directories() command passed
In CMake 2.8.0 and lower the :command:`link_directories` command passed
relative paths unchanged to the linker. In CMake 2.8.1 and above the
link_directories() command prefers to interpret relative paths with
respect to CMAKE_CURRENT_SOURCE_DIR, which is consistent with
include_directories() and other commands. The ``OLD`` behavior for this
policy is to use relative paths verbatim in the linker command. The
:command:`link_directories` command prefers to interpret relative paths with
respect to ``CMAKE_CURRENT_SOURCE_DIR``, which is consistent with
:command:`include_directories` and other commands. The ``OLD`` behavior for
this policy is to use relative paths verbatim in the linker command. The
``NEW`` behavior for this policy is to convert relative paths to absolute
paths by appending the relative path to CMAKE_CURRENT_SOURCE_DIR.
paths by appending the relative path to ``CMAKE_CURRENT_SOURCE_DIR``.
This policy was introduced in CMake version 2.8.1. CMake version
|release| warns when the policy is not set and uses ``OLD`` behavior. Use
......
......@@ -5,12 +5,12 @@ Prefer files from the CMake module directory when including from there.
Starting with CMake 2.8.4, if a cmake-module shipped with CMake (i.e.
located in the CMake module directory) calls :command:`include` or
find_package(), the files located in the CMake module directory are
:command:`find_package`, the files located in the CMake module directory are
preferred over the files in :variable:`CMAKE_MODULE_PATH`. This makes sure
that the modules belonging to CMake always get those files included which
they expect, and against which they were developed and tested. In all
other cases, the files found in :variable:`CMAKE_MODULE_PATH` still take
precedence over the ones in the CMake module directory. The OLD
precedence over the ones in the CMake module directory. The ``OLD``
behavior is to always prefer files from CMAKE_MODULE_PATH over files
from the CMake modules directory.
......
......@@ -10,8 +10,9 @@ as :manual:`cmake-generator-expressions(7)` and some
diagnostics expect target names to match a restricted pattern.
Target names may contain upper and lower case letters, numbers, the underscore
character (_), dot(.), plus(+) and minus(-). As a special case, ALIAS
targets and ``IMPORTED`` targets may contain two consecutive colons.
character (``_``), dot(``.``), plus(``+``) and minus(``-``).
As a special case, ``ALIAS`` and ``IMPORTED`` targets may contain
two consecutive colons.
Target names reserved by one or more CMake generators are not allowed.
Among others these include ``all``, ``clean``, ``help``, and ``install``.
......
......@@ -3,5 +3,5 @@ ADDITIONAL_MAKE_CLEAN_FILES
Additional files to clean during the make clean stage.
A list of files that will be cleaned as a part of the "make clean"
A list of files that will be cleaned as a part of the ``make clean``
stage.
IMPLICIT_DEPENDS_INCLUDE_TRANSFORM
----------------------------------
Specify #include line transforms for dependencies in a directory.
Specify ``#include`` line transforms for dependencies in a directory.
This property specifies rules to transform macro-like #include lines
This property specifies rules to transform macro-like ``#include`` lines
during implicit dependency scanning of C and C++ source files. The
list of rules must be semicolon-separated with each entry of the form
"A_MACRO(%)=value-with-%" (the % must be literal). During dependency
scanning occurrences of A_MACRO(...) on #include lines will be
``A_MACRO(%)=value-with-%`` (the ``%`` must be literal). During dependency
scanning occurrences of ``A_MACRO(...)`` on ``#include`` lines will be
replaced by the value given with the macro argument substituted for
'%'. For example, the entry
``%``. For example, the entry
::
......
......@@ -3,6 +3,6 @@ INTERPROCEDURAL_OPTIMIZATION_<CONFIG>
Per-configuration interprocedural optimization for a directory.
This is a per-configuration version of INTERPROCEDURAL_OPTIMIZATION.
This is a per-configuration version of ``INTERPROCEDURAL_OPTIMIZATION``.
If set, this property overrides the generic property for the named
configuration.
......@@ -4,5 +4,5 @@ MACROS
List of macro commands available in the current directory.
This read-only property specifies the list of CMake macros currently
defined. It is intended for debugging purposes. See the macro
defined. It is intended for debugging purposes. See the :command:`macro`
command.
......@@ -3,5 +3,6 @@ TESTS
List of tests.
This read-only property holds a :ref:`semicolon-separated list <CMake Language Lists>` of tests
This read-only property holds a
:ref:`semicolon-separated list <CMake Language Lists>` of tests
defined so far, in the current directory, by the :command:`add_test` command.
......@@ -12,20 +12,20 @@ in the solution file:
<contents based on property value>
EndGlobalSection
The property must be set to a semicolon-separated list of key=value
The property must be set to a semicolon-separated list of ``key=value``
pairs. Each such pair will be transformed into an entry in the
solution global section. Whitespace around key and value is ignored.
List elements which do not contain an equal sign are skipped.
This property only works for Visual Studio 9 and above; it is ignored
on other generators. The property only applies when set on a
directory whose CMakeLists.txt contains a project() command.
directory whose ``CMakeLists.txt`` contains a :command:`project` command.
Note that CMake generates postSolution sections ExtensibilityGlobals
and ExtensibilityAddIns by default. If you set the corresponding
Note that CMake generates postSolution sections ``ExtensibilityGlobals``
and ``ExtensibilityAddIns`` by default. If you set the corresponding
property, it will override the default section. For example, setting
VS_GLOBAL_SECTION_POST_ExtensibilityGlobals will override the default
contents of the ExtensibilityGlobals section, while keeping
``VS_GLOBAL_SECTION_POST_ExtensibilityGlobals`` will override the default
contents of the ``ExtensibilityGlobals`` section, while keeping
ExtensibilityAddIns on its default. However, CMake will always
add a ``SolutionGuid`` to the ``ExtensibilityGlobals`` section
if it is not specified explicitly.
......@@ -12,11 +12,11 @@ in the solution file:
<contents based on property value>
EndGlobalSection
The property must be set to a semicolon-separated list of key=value
The property must be set to a semicolon-separated list of ``key=value``
pairs. Each such pair will be transformed into an entry in the
solution global section. Whitespace around key and value is ignored.
List elements which do not contain an equal sign are skipped.
This property only works for Visual Studio 9 and above; it is ignored
on other generators. The property only applies when set on a
directory whose CMakeLists.txt contains a project() command.
directory whose ``CMakeLists.txt`` contains a :command:`project` command.
......@@ -7,7 +7,7 @@ The :ref:`Visual Studio Generators` create a ``.sln`` file for each directory
whose ``CMakeLists.txt`` file calls the :command:`project` command. Set this
property in the same directory as a :command:`project` command call (e.g. in
the top-level ``CMakeLists.txt`` file) to specify the default startup project
for the correpsonding solution file.
for the corresponding solution file.
The property must be set to the name of an existing target. This
will cause that project to be listed first in the generated solution
......
......@@ -4,16 +4,18 @@ ALLOW_DUPLICATE_CUSTOM_TARGETS
Allow duplicate custom targets to be created.
Normally CMake requires that all targets built in a project have
globally unique logical names (see policy CMP0002). This is necessary
to generate meaningful project file names in Xcode and VS IDE
globally unique logical names (see policy :policy:`CMP0002`).
This is necessary to generate meaningful project file names in
:generator:`Xcode` and :ref:`Visual Studio Generators` IDE
generators. It also allows the target names to be referenced
unambiguously.
Makefile generators are capable of supporting duplicate custom target
names. For projects that care only about Makefile generators and do
not wish to support Xcode or VS IDE generators, one may set this
property to true to allow duplicate custom targets. The property
allows multiple add_custom_target command calls in different
Makefile generators are capable of supporting duplicate :command:`add_custom_target`
names. For projects that care only about :ref:`Makefile Generators` and do
not wish to support :generator:`Xcode` or :ref:`Visual Studio Generators` IDE
generators, one may set this property to ``True``
to allow duplicate custom targets. The property
allows multiple :command:`add_custom_target` command calls in different
directories to specify the same target name. However, setting this
property will cause non-Makefile generators to produce an error and
refuse to generate the project.
......@@ -5,7 +5,7 @@ List of features which are disabled during the CMake run.
List of features which are disabled during the CMake run. By default
it contains the names of all packages which were not found. This is
determined using the <NAME>_FOUND variables. Packages which are
searched QUIET are not listed. A project can add its own features to
determined using the ``<NAME>_FOUND`` variables. Packages which are
searched ``QUIET`` are not listed. A project can add its own features to
this list. This property is used by the macros in
FeatureSummary.cmake.
``FeatureSummary.cmake``.
......@@ -5,7 +5,7 @@ List of features which are enabled during the CMake run.
List of features which are enabled during the CMake run. By default
it contains the names of all packages which were found. This is
determined using the <NAME>_FOUND variables. Packages which are
searched QUIET are not listed. A project can add its own features to
determined using the ``<NAME>_FOUND`` variables. Packages which are
searched ``QUIET`` are not listed. A project can add its own features to
this list. This property is used by the macros in
FeatureSummary.cmake.
``FeatureSummary.cmake``.
......@@ -4,7 +4,7 @@ USE_FOLDERS
Use the :prop_tgt:`FOLDER` target property to organize targets into
folders.
If not set, CMake treats this property as OFF by default. CMake
If not set, CMake treats this property as ``OFF`` by default. CMake
generators that are capable of organizing into a hierarchy of folders
use the values of the :prop_tgt:`FOLDER` target property to name those
folders. See also the documentation for the FOLDER target property.
folders. See also the documentation for the :prop_tgt:`FOLDER` target property.
XCODE_EMIT_EFFECTIVE_PLATFORM_NAME
----------------------------------
Control emission of ``EFFECTIVE_PLATFORM_NAME`` by the Xcode generator.
Control emission of ``EFFECTIVE_PLATFORM_NAME`` by the :generator:`Xcode`
generator.
It is required for building the same target with multiple SDKs. A
common use case is the parallel use of ``iphoneos`` and
``iphonesimulator`` SDKs.
Three different states possible that control when the Xcode generator
emits the ``EFFECTIVE_PLATFORM_NAME`` variable:
Three different states possible that control when the :generator:`Xcode`
generator emits the ``EFFECTIVE_PLATFORM_NAME`` variable:
- If set to ``ON`` it will always be emitted
- If set to ``OFF`` it will never be emitted
......
CPACK_DESKTOP_SHORTCUTS
-----------------------
Species a list of shortcut names that should be created on the Desktop
Species a list of shortcut names that should be created on the `Desktop`
for this file.
The property is currently only supported by the WIX generator.
The property is currently only supported by the :cpack_gen:`CPack WIX Generator`.
......@@ -3,4 +3,4 @@ CPACK_NEVER_OVERWRITE
Request that this file not be overwritten on install or reinstall.
The property is currently only supported by the WIX generator.
The property is currently only supported by the :cpack_gen:`CPack WIX Generator`.
......@@ -3,4 +3,4 @@ CPACK_PERMANENT
Request that this file not be removed on uninstall.
The property is currently only supported by the WIX generator.
The property is currently only supported by the :cpack_gen:`CPack WIX Generator`.
CPACK_STARTUP_SHORTCUTS
-----------------------