Help: add and make references to generators consistent

Help/command/add_custom_command.rst

@@ -282,7 +282,7 @@ The options are:
 ``MAIN_DEPENDENCY``
   Specify the primary input source file to the command.  This is
   treated just like any value given to the ``DEPENDS`` option
-  but also suggests to Visual Studio generators where to hang
+  but also suggests to :ref:`Visual Studio Generators` where to hang
   the custom command. Each source file may have at most one command
   specifying it as its main dependency. A compile command (i.e. for a
   library or an executable) counts as an implicit main dependency which

Help/command/add_library.rst

@@ -120,9 +120,9 @@ may contain only sources that compile, header files, and other files
 that would not affect linking of a normal library (e.g. ``.txt``).
 They may contain custom commands generating such sources, but not
 ``PRE_BUILD``, ``PRE_LINK``, or ``POST_BUILD`` commands.  Some native build
-systems (such as Xcode) may not like targets that have only object files, so
-consider adding at least one real source file to any target that references
-:genex:`$\<TARGET_OBJECTS:objlib\> <TARGET_OBJECTS>`.
+systems (such as :generator:`Xcode`) may not like targets that have only
+object files, so consider adding at least one real source file to any target
+that references :genex:`$\<TARGET_OBJECTS:objlib\> <TARGET_OBJECTS>`.
 
 .. versionadded:: 3.12
   Object libraries can be linked to with :command:`target_link_libraries`.

Help/command/link_directories.rst

@@ -40,8 +40,8 @@ The command will apply only to targets created after it is called.
   generally be used directly in calls to :command:`target_link_libraries`.
   Situations where a library search path may be needed include:
 
-  - Project generators like Xcode where the user can switch target
-    architecture at build time, but a full path to a library cannot
+  - Project generators like :generator:`Xcode` where the user can switch
+    target architecture at build time, but a full path to a library cannot
     be used because it only provides one architecture (i.e. it is not
     a universal binary).
   - Libraries may themselves have other private library dependencies

Help/command/target_link_directories.rst

@@ -46,8 +46,8 @@ property instead of being appended.
   generally be used directly in calls to :command:`target_link_libraries`.
   Situations where a library search path may be needed include:
 
-  - Project generators like Xcode where the user can switch target
-    architecture at build time, but a full path to a library cannot
+  - Project generators like :generator:`Xcode` where the user can switch
+    target architecture at build time, but a full path to a library cannot
     be used because it only provides one architecture (i.e. it is not
     a universal binary).
   - Libraries may themselves have other private library dependencies

Help/dev/testing.rst

@@ -26,9 +26,9 @@ using `ctest(1)`_:
     $ ctest
 
 * With a multi-configuration CMake generator, such as
-  ``Ninja Multi-Config``, ``Visual Studio``, or ``Xcode``,
-  one must tell ``ctest`` which configuration to test
-  by passing the ``-C <config>`` option:
+  :generator:`Ninja Multi-Config`, :generator:`Visual Studio <Visual Studio
+  Generators>`, or :generator:`Xcode`, one must tell ``ctest`` which
+  configuration to test by passing the ``-C <config>`` option:
 
   .. code-block:: console
 

Help/guide/ide-integration/index.rst

@@ -115,8 +115,9 @@ recommended that the IDE invoke :manual:`cmake(1)` with the
 appropriate build tool.
 
 If an IDE project generator is used, such as :generator:`Xcode` or one of the
-Visual Studio generators, and the IDE understands the project format used, the
-IDE should read the project file and build it the same way it would otherwise.
+:ref:`Visual Studio Generators`, and the IDE understands the project format
+used, the IDE should read the project file and build it the same way it would
+otherwise.
 
 The :manual:`File API <cmake-file-api(7)>` can be used to obtain a list of
 build configurations from the build tree, and the IDE should present this list
@@ -154,7 +155,8 @@ The following IDEs support CMake natively:
 Additionally, CMake has builtin support for some IDEs:
 
 * :ref:`IDE Build Tool Generators`:
-  Generate IDE native build systems such as Visual Studio or Xcode.
+  Generate IDE native build systems such as
+  :ref:`Visual Studio <Visual Studio Generators>` or :generator:`Xcode`.
 * :ref:`Extra Generators`:
   Extend :ref:`Command-Line Build Tool Generators` to generate IDE
   project files that hook into the command-line build system.

Help/guide/user-interaction/index.rst

@@ -129,7 +129,7 @@ not strictly necessary to use a corresponding
 command line environment when using a Visual Studio
 generator, doing so has no disadvantages.
 
-When using Xcode, there can be more than one Xcode
+When using :generator:`Xcode`, there can be more than one Xcode
 version installed.  Which one to use can be selected
 in a number of different ways, but the most common
 methods are:
@@ -195,7 +195,7 @@ VisualC++ compiler, or a combination of the two:
   $ cmake .. -G "Visual Studio 16"
   $ cmake .. -G "Visual Studio 16 2019"
 
-Visual Studio generators can target different architectures.
+:ref:`Visual Studio Generators` can target different architectures.
 One can specify the target architecture using the
 :option:`-A <cmake -A>` option:
 
@@ -285,8 +285,10 @@ the table below:
                                             ``Debug`` or ``Release``, determining
                                             debug/optimization flags.  This is only
                                             relevant for single-configuration buildsystems such
-                                            as ``Makefile`` and ``Ninja``.  Multi-configuration
-                                            buildsystems such as those for Visual Studio and Xcode
+                                            as :ref:`Makefile Generators` and
+                                            :ref:`Ninja Generators`.
+                                            Multi-configuration buildsystems such as those for
+                                            :ref:`Visual Studio Generators` and :generator`Xcode`
                                             ignore this setting.
  :variable:`CMAKE_INSTALL_PREFIX`           Location to install the
                                             software to with the
@@ -572,21 +574,21 @@ CMake provides some built-in targets for all buildsystems
 providing CMake files.
 
 ``all``
-  The default target used by ``Makefile`` and ``Ninja``
-  generators.  Builds all targets in the buildsystem,
-  except those which are excluded by their
-  :prop_tgt:`EXCLUDE_FROM_ALL` target property or
+  The default target used by :ref:`Makefile Generators`
+  and :ref:`Ninja Generators`.  Builds all targets in
+  the buildsystem, except those which are excluded by
+  their :prop_tgt:`EXCLUDE_FROM_ALL` target property or
   :prop_dir:`EXCLUDE_FROM_ALL` directory property.  The
   name ``ALL_BUILD`` is used for this purpose for the
-  Xcode and Visual Studio generators.
+  :generator:`Xcode` and :ref:`Visual Studio Generators`.
 ``help``
   Lists the targets available for build.  This target is
-  available when using the :generator:`Unix Makefiles` or
-  :generator:`Ninja` generator, and the exact output is
+  available when using the :ref:`Makefile Generators` or
+  :ref:`Ninja Generators`, and the exact output is
   tool-specific.
 ``clean``
   Delete built object files and other output files.  The
-  ``Makefile`` based generators create a ``clean`` target
+  :ref:`Makefile Generators` create a ``clean`` target
   per directory, so that an individual directory can be
   cleaned.  The ``Ninja`` tool provides its own granular
   ``-t clean`` system.
@@ -608,15 +610,15 @@ providing CMake files.
   automatically available if the CMake files provide
   CPack-based packages.
 
-For ``Makefile`` based systems, ``/fast`` variants of binary
+For :ref:`Makefile Generators`, ``/fast`` variants of binary
 build targets are provided. The ``/fast`` variants are used
 to build the specified target without regard for its
 dependencies.  The dependencies are not checked and
-are not rebuilt if out of date.  The :generator:`Ninja`
-generator is sufficiently fast at dependency checking that
+are not rebuilt if out of date.  The :ref:`Ninja Generators`
+are sufficiently fast at dependency checking that
 such targets are not provided for that generator.
 
-``Makefile`` based systems also provide build-targets to
+:ref:`Makefile Generators` also provide build-targets to
 preprocess, assemble and compile individual files in a
 particular directory.
 

Help/manual/cmake-file-api.7.rst

@@ -1158,8 +1158,8 @@ with members:
   ``workingDirectory``
     Optional member that is present when the DEBUGGER_WORKING_DIRECTORY
     target property is set.
-    The member will also be present in Visual Studio Generator
-    scenarios when VS_DEBUGGER_WORKING_DIRECTORY is set.
+    The member will also be present in :ref:`Visual Studio Generators`
+    when VS_DEBUGGER_WORKING_DIRECTORY is set.
 
     This field was added in codemodel version 2.8.
 

Help/manual/cmake-qt.7.rst

@@ -250,7 +250,7 @@ custom command, without forcing the custom command to re-execute.
 Visual Studio Generators
 ========================
 
-When using the :manual:`Visual Studio generators <cmake-generators(7)>`, CMake
+When using the :ref:`Visual Studio Generators`, CMake
 generates a ``PRE_BUILD`` :command:`custom command <add_custom_command>`
 instead of the :ref:`<ORIGIN>_autogen`
 :command:`custom target <add_custom_target>` (for :prop_tgt:`AUTOMOC` and

Help/manual/cmake-toolchains.7.rst

@@ -251,7 +251,7 @@ Cross compiling for Windows CE requires the corresponding SDK being
 installed on your system.  These SDKs are usually installed under
 ``C:/Program Files (x86)/Windows CE Tools/SDKs``.
 
-A toolchain file to configure a Visual Studio generator for
+A toolchain file to configure :ref:`Visual Studio Generators` for
 Windows CE may look like this:
 
 .. code-block:: cmake
@@ -291,7 +291,7 @@ CMake selects a Windows SDK as described by documentation of the
 Cross Compiling for Windows Phone
 ---------------------------------
 
-A toolchain file to configure a Visual Studio generator for
+A toolchain file to configure :ref:`Visual Studio Generators` for
 Windows Phone may look like this:
 
 .. code-block:: cmake
@@ -302,7 +302,7 @@ Windows Phone may look like this:
 Cross Compiling for Windows Store
 ---------------------------------
 
-A toolchain file to configure a Visual Studio generator for
+A toolchain file to configure a :ref:`Visual Studio Generators` for
 Windows Store may look like this:
 
 .. code-block:: cmake

Help/manual/cmake.1.rst

@@ -712,7 +712,7 @@ following options:
   specific cache variable will be evaluated to decide, if package restoration
   should be performed.
 
-  When using the Visual Studio generator, package references are defined
+  When using :ref:`Visual Studio Generators`, package references are defined
   using the :prop_tgt:`VS_PACKAGE_REFERENCES` property. Package references
   are restored using NuGet. It can be disabled by setting the
   ``CMAKE_VS_NUGET_PACKAGE_RESTORE`` variable to ``OFF``.

Help/manual/cpack.1.rst

@@ -57,7 +57,8 @@ Options
   ``Release``, etc.), where ``<configurations>`` is a
   :ref:`semicolon-separated list <CMake Language Lists>`.
   When the CMake project uses a multi-configuration
-  generator such as Xcode or Visual Studio, this option is needed to tell
+  generator such as :generator:`Xcode` or
+  :ref:`Visual Studio <Visual Studio Generators>`, this option is needed to tell
   :program:`cpack` which built executables to include in the package.
   The user is responsible for ensuring that the configuration(s) listed
   have already been built before invoking :program:`cpack`.

Help/policy/CMP0002.rst

@@ -12,7 +12,8 @@ names must be globally unique because:
 
 * Unique names may be referenced unambiguously both in CMake
   code and on make tool command lines.
-* Logical names are used by Xcode and VS IDE generators
+* Logical names are used by :generator:`Xcode` and
+  :ref:`Visual Studio <Visual Studio Generators>` IDE generators
   to produce meaningful project names for the targets.
 
 The logical name of executable and library targets does not have to

Help/policy/CMP0132.rst

@@ -5,9 +5,9 @@ CMP0132
 
 Do not set compiler environment variables on first run.
 
-Apart from when using the Xcode generator and some Visual Studio generators,
-CMake 3.23 and below will set environment variables like :envvar:`CC`,
-:envvar:`CXX`, etc. when the corresponding language is enabled.
+Apart from when using the :generator:`Xcode` generator and some :ref:`Visual
+Studio Generators`, CMake 3.23 and below will set environment variables like
+:envvar:`CC`, :envvar:`CXX`, etc. when the corresponding language is enabled.
 This only occurs on the very first time CMake is run in a build directory,
 and the environment variables are only defined at configure time, not build
 time. On subsequent CMake runs, these environment variables are not set,

Help/prop_sf/COMPILE_DEFINITIONS.rst

@@ -13,7 +13,7 @@ the name ``COMPILE_DEFINITIONS_<CONFIG>`` where ``<CONFIG>`` is an upper-case
 name (ex.  ``COMPILE_DEFINITIONS_DEBUG``).
 
 CMake will automatically drop some definitions that are not supported
-by the native build tool.  Xcode does not support per-configuration
+by the native build tool.  :generator:`Xcode` does not support per-configuration
 definitions on source files.
 
 .. versionadded:: 3.26

Help/prop_sf/VS_CSHARP_tagname.rst

@@ -5,7 +5,7 @@ VS_CSHARP_<tagname>
 
 Visual Studio and CSharp source-file-specific configuration.
 
-Tell the :manual:`Visual Studio generators <cmake-generators(7)>`
+Tell the :ref:`Visual Studio Generators`
 to set the source file tag ``<tagname>``
 to a given value in the generated Visual Studio CSharp
 project. Ignored on other generators and languages. This property

Help/prop_sf/VS_DEPLOYMENT_CONTENT.rst

@@ -5,7 +5,7 @@ VS_DEPLOYMENT_CONTENT
 
 Mark a source file as content for deployment with a Windows Phone or
 Windows Store application when built with a
-:manual:`Visual Studio generators <cmake-generators(7)>`.
+:ref:`Visual Studio Generators`.
 The value must evaluate to either ``1`` or ``0`` and may use
 :manual:`generator expressions <cmake-generator-expressions(7)>`
 to make the choice based on the build configuration.

Help/prop_tgt/ARCHIVE_OUTPUT_DIRECTORY_CONFIG.rst

@@ -6,8 +6,9 @@ Per-configuration output directory for
 
 This is a per-configuration version of the
 :prop_tgt:`ARCHIVE_OUTPUT_DIRECTORY` target property, but
-multi-configuration generators (VS, Xcode) do NOT append a
-per-configuration subdirectory to the specified directory.  This
+multi-configuration generators (:ref:`Visual Studio <Visual Studio
+Generators>`, :generator:`Xcode`, :generator:`Ninja Multi-Config`) do NOT
+append a per-configuration subdirectory to the specified directory.  This
 property is initialized by the value of the
 :variable:`CMAKE_ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>` variable if
 it is set when a target is created.

Help/prop_tgt/COMMON_LANGUAGE_RUNTIME.rst

@@ -6,7 +6,7 @@ COMMON_LANGUAGE_RUNTIME
 By setting this target property, the target is configured to build with
 ``C++/CLI`` support.
 
-The Visual Studio generator defines the ``clr`` parameter depending on
+The :ref:`Visual Studio Generators` define the ``clr`` parameter depending on
 the value of the ``COMMON_LANGUAGE_RUNTIME`` target property:
 
 Not Set (default)

Help/prop_tgt/COMPILE_PDB_OUTPUT_DIRECTORY_CONFIG.rst

@@ -8,8 +8,9 @@ generated by the compiler while building source files.
 
 This is a per-configuration version of
 :prop_tgt:`COMPILE_PDB_OUTPUT_DIRECTORY`,
-but multi-configuration generators (Visual Studio, Xcode) do NOT append a
-per-configuration subdirectory to the specified directory.  This
+but multi-configuration generators (:ref:`Visual Studio <Visual Studio
+Generators>`, :generator:`Xcode`, :generator:`Ninja Multi-Config`) do NOT
+append a per-configuration subdirectory to the specified directory.  This
 property is initialized by the value of the
 :variable:`CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>` variable
 if it is set when a target is created.

Help/prop_tgt/DEBUGGER_WORKING_DIRECTORY.rst

@@ -12,7 +12,8 @@ created.
 
 If the :prop_tgt:`VS_DEBUGGER_WORKING_DIRECTORY` property is also set, it will
 take precedence over ``DEBUGGER_WORKING_DIRECTORY`` when using one of the
-Visual Studio generators.
+:ref:`Visual Studio Generators`.
 
 Similarly, if :prop_tgt:`XCODE_SCHEME_WORKING_DIRECTORY` is set, it will
-override ``DEBUGGER_WORKING_DIRECTORY`` when using the Xcode generator.
+override ``DEBUGGER_WORKING_DIRECTORY`` when using the :generator:`Xcode`
+generator.

Help/prop_tgt/EXCLUDE_FROM_DEFAULT_BUILD.rst

@@ -3,9 +3,9 @@ EXCLUDE_FROM_DEFAULT_BUILD
 
 Exclude a target from the solution build configuration.
 
-This property is only used by Visual Studio generators. When set to ``TRUE``,
-the target will be excluded from the build when the "Build Solution" command
-is run.
+This property is only used by :ref:`Visual Studio Generators`. When set to
+``TRUE``, the target will be excluded from the build when the "Build Solution"
+command is run.
 
 This property has a per-configuration version:
 :prop_tgt:`EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG>`.

Help/prop_tgt/FRAMEWORK_MULTI_CONFIG_POSTFIX_CONFIG.rst

@@ -4,7 +4,8 @@ FRAMEWORK_MULTI_CONFIG_POSTFIX_<CONFIG>
 .. versionadded:: 3.18
 
 Postfix to append to the framework file name for configuration ``<CONFIG>``,
-when using a multi-config generator (like Xcode and Ninja Multi-Config).
+when using a multi-config generator (like :generator:`Xcode` and
+:generator:`Ninja Multi-Config`).
 
 When building with configuration ``<CONFIG>`` the value of this property
 is appended to the framework file name built on disk.

Help/prop_tgt/IMPORTED_OBJECTS_CONFIG.rst

@@ -12,9 +12,9 @@ which the target is imported.
 Xcode Generator Considerations
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Do not use this ``<CONFIG>``-specific property if you need to use Xcode
-variables like ``$(CURRENT_ARCH)`` or ``$(EFFECTIVE_PLATFORM_NAME)`` in
-the value.  The ``<CONFIG>``-specific properties will be ignored in such
-cases because CMake cannot determine whether a file exists at the
-configuration-specific path at configuration time.  For such cases, use
-:prop_tgt:`IMPORTED_OBJECTS` instead.
+Do not use this ``<CONFIG>``-specific property if you need to use
+:generator:`Xcode` variables like ``$(CURRENT_ARCH)`` or
+``$(EFFECTIVE_PLATFORM_NAME)`` in the value.  The ``<CONFIG>``-specific
+properties will be ignored in such cases because CMake cannot determine
+whether a file exists at the configuration-specific path at configuration
+time.  For such cases, use :prop_tgt:`IMPORTED_OBJECTS` instead.

Help/prop_tgt/VS_GLOBAL_variable.rst

@@ -3,7 +3,7 @@ VS_GLOBAL_<variable>
 
 Visual Studio project-specific global variable.
 
-Tell the Visual Studio generator to set the global variable
+Tell the :ref:`Visual Studio Generators` to set the global variable
 '<variable>' to a given value in the generated Visual Studio project.
 Ignored on other generators.  Qt integration works better if
 VS_GLOBAL_QtVersion is set to the version FindQt4.cmake found.  For

Help/prop_tgt/VS_SOURCE_SETTINGS_tool.rst

@@ -5,7 +5,7 @@ VS_SOURCE_SETTINGS_<tool>
 
 Set any item metadata on all non-built files that use <tool>.
 
-Takes a list of ``Key=Value`` pairs. Tells the Visual Studio generator
+Takes a list of ``Key=Value`` pairs. Tells the :ref:`Visual Studio Generators`
 to set ``Key`` to ``Value`` as item metadata on all non-built files
 that use ``<tool>``.
 

Help/prop_tgt/VS_WINRT_COMPONENT.rst

@@ -3,11 +3,11 @@ VS_WINRT_COMPONENT
 
 .. versionadded:: 3.1
 
-Mark a target as a Windows Runtime component for the Visual Studio generator.
+Mark a target as a Windows Runtime component for the :ref:`Visual Studio Generators`.
 Compile the target with ``C++/CX`` language extensions for Windows Runtime.
 For ``SHARED`` and ``MODULE`` libraries, this also defines the
 ``_WINRT_DLL`` preprocessor macro.
 
 .. note::
-  Currently this is implemented only by Visual Studio generators.
+  Currently this is implemented only by :ref:`Visual Studio Generators`.
   Support may be added to other generators in the future.

Help/variable/CMAKE_VS_NUGET_PACKAGE_RESTORE.rst

@@ -3,7 +3,7 @@ CMAKE_VS_NUGET_PACKAGE_RESTORE
 
 .. versionadded:: 3.23
 
-When using a Visual Studio generator, this cache variable controls
+When using :ref:`Visual Studio Generators`, this cache variable controls
 if msbuild should automatically attempt to restore NuGet packages
 prior to a build. NuGet packages can be defined using the
 :prop_tgt:`VS_PACKAGE_REFERENCES` property on a target. If no

Help/variable/CMAKE_VS_NsightTegra_VERSION.rst

@@ -3,7 +3,7 @@ CMAKE_VS_NsightTegra_VERSION
 
 .. versionadded:: 3.1
 
-When using a Visual Studio generator with the
+When using :ref:`Visual Studio Generators` with the
 :variable:`CMAKE_SYSTEM_NAME` variable set to ``Android``,
 this variable contains the version number of the
 installed NVIDIA Nsight Tegra Visual Studio Edition.

Modules/CSharpUtilities.cmake

@@ -9,7 +9,7 @@ CSharpUtilities
 
 This utility module is intended to simplify the configuration of CSharp/.NET
 targets and provides a collection of commands for managing CSharp targets
-with Visual Studio generators, version 2010 and newer.
+with :ref:`Visual Studio Generators`, version 2010 and newer.
 
 Load this module in a CMake project with:
 

Modules/CheckIPOSupported.cmake

@@ -81,7 +81,7 @@ This module provides the following command:
     ``NEW``; otherwise, a fatal error will occur.
 
   .. versionadded:: 3.13
-    Support for Visual Studio generators.
+    Support for :ref:`Visual Studio Generators`.
 
   .. versionadded:: 3.24
     The check uses the caller's :variable:`CMAKE_<LANG>_FLAGS`