code:
CMake 3.8 Release Notes
***********************

.. only:: html

  .. contents::

Changes made since CMake 3.7 include the following.

New Features
============

Languages
---------

C#
^^

* CMake learned to support ``CSharp`` (C#) as a first-class language that
  can be enabled via the :command:`project` and :command:`enable_language`
  commands.  It is currently supported by the :ref:`Visual Studio Generators`
  for VS 2010 and above.

  C# assemblies and programs can be added just like common C++ targets using
  the :command:`add_library` and :command:`add_executable` commands.
  References between C# targets in the same source tree may be specified by
  :command:`target_link_libraries` like for C++.  References to system or
  3rd-party assemblies may be specified by the target properties
  :prop_tgt:`VS_DOTNET_REFERENCE_<refname>` and
  :prop_tgt:`VS_DOTNET_REFERENCES`.

* More fine tuning of C# targets may be done using target and source
  file properties.  Specifically the target properties related to
  Visual Studio (``VS_*``) are worth a look (for setting toolset
  versions, root namespaces, assembly icons, ...).

CUDA
^^^^

* CMake learned to support ``CUDA`` as a first-class language that can be
  enabled via the :command:`project` and :command:`enable_language` commands.

* ``CUDA`` is currently supported by the :ref:`Makefile Generators`
  and the :generator:`Ninja` generator on Linux, macOS, and Windows.
  Support for the Visual Studio IDE is under development but not
  included in this release.

* The NVIDIA CUDA Toolkit compiler (``nvcc``) is supported.

C & C++
^^^^^^^

* The :manual:`Compile Features <cmake-compile-features(7)>` functionality
  now offers meta-features that request compiler modes for specific language
  standard levels (e.g. ``cxx_std_11``).  See
  :prop_gbl:`CMAKE_C_KNOWN_FEATURES` and :prop_gbl:`CMAKE_CXX_KNOWN_FEATURES`.

* The :manual:`Compile Features <cmake-compile-features(7)>` functionality
  is now aware of C++ 17.  No specific features are yet enumerated besides
  the ``cxx_std_17`` meta-feature.

* The :manual:`Compile Features <cmake-compile-features(7)>` functionality
  is now aware of the availability of C99 in gcc since version 3.4.

Platforms
---------

* A new minimal platform file for ``Fuchsia`` was added.

Generators
----------

* The :generator:`CodeBlocks` extra generator may now be used to
  generate with :generator:`NMake Makefiles JOM`.

* The :ref:`Visual Studio Generators` for VS 2013 and above learned to
  support a ``host=x64`` option in the :variable:`CMAKE_GENERATOR_TOOLSET`
  value (e.g.  via the :manual:`cmake(1)` ``-T`` option) to request use
  of a VS 64-bit toolchain on 64-bit hosts.

* The :ref:`Visual Studio Generators` learned to treat files passed to
  :command:`target_link_libraries` whose names end in ``.targets``
  as MSBuild "targets" files to be imported into generated project files.

Commands
--------

* The :command:`add_custom_command` and :command:`add_custom_target` commands
  learned the option ``COMMAND_EXPAND_LISTS`` which causes lists in the
  ``COMMAND`` argument to be expanded, including lists created by generator
  expressions.

* The :command:`execute_process` command gained an ``ENCODING`` option to
  specify on Windows which encoding is used for output from child process.

* The :command:`math(EXPR)` command gained support for unary
  ``+`` and ``-`` operators.

* The :command:`source_group` command gained ``TREE`` and ``PREFIX``
  options to add groups following source tree directory structure.

* The :command:`string(TIMESTAMP)` command learned to treat ``%%``
  as a way to encode plain ``%``.

* The :command:`string(TIMESTAMP)` command will now honor the
  ``SOURCE_DATE_EPOCH`` environment variable and use its value
  instead of the current time.

* The :command:`try_compile` command source file signature gained new options
  to specify the language standard to use in the generated test project.

* The :command:`try_compile` command source file signature now honors
  language standard variables like :variable:`CMAKE_CXX_STANDARD`.
  See policy :policy:`CMP0067`.

Variables
---------

* A :variable:`CMAKE_CODELITE_USE_TARGETS` variable was added to tell the
  :generator:`CodeLite` extra generator to change the generated project
  to have target-centric organization.
  The ``build``, ``rebuild``, and ``clean`` operations within ``CodeLite``
  then work on a selected target rather than the whole workspace.
  (Note that the :generator:`Ninja` clean operation on a target
  includes its dependencies, though.)

* The :variable:`CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS` variable was added to
  tell the :generator:`Sublime Text 2` extra generator to place specified
  environment variables in the generated ``.sublime-project``.

* The :variable:`CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE` variable was added
  to tell the :generator:`Sublime Text 2` extra generator whether to exclude
  the build tree from the ``.sublime-project`` when it is inside the source
  tree.

* A :variable:`CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD` variable was
  added to tell :ref:`Visual Studio Generators` for VS 2010 and above
  to include the ``PACKAGE`` target in the default build, similar to
  the existing :variable:`CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD`
  variable for the ``INSTALL`` target.

Properties
----------

* A :prop_tgt:`BUILD_RPATH` target property and corresponding
  :variable:`CMAKE_BUILD_RPATH` variable were added to support custom
  ``RPATH`` locations to be added to binaries in the build tree.

* The :prop_sf:`COMPILE_FLAGS` source file property learned to support
  :manual:`generator expressions <cmake-generator-expressions(7)>`.

* The :prop_tgt:`FRAMEWORK` target property may now also be applied to
  static libraries on Apple targets.  It will result in a proper
  Framework but with a static library inside.

* :ref:`Imported <Imported Targets>` :ref:`Interface Libraries` learned new
  :prop_tgt:`IMPORTED_LIBNAME` and :prop_tgt:`IMPORTED_LIBNAME_<CONFIG>`
  target properties to specify a link library name since interface libraries
  do not build their own library files.

* A :prop_tgt:`<LANG>_CPPLINT` target property and supporting
  :variable:`CMAKE_<LANG>_CPPLINT` variable were introduced to tell
  the :ref:`Makefile Generators` and the :generator:`Ninja` generator to
  run the ``cpplint`` style checker along with the compiler for ``C`` and
  ``CXX`` languages.

* A :prop_tgt:`MANUALLY_ADDED_DEPENDENCIES` target property has been added.
  It provides a read-only list of dependencies that have been added with
  the :command:`add_dependencies` command.

* The :prop_tgt:`MAP_IMPORTED_CONFIG_<CONFIG>` target property learned
  to interpret empty list elements as referring to the configuration-less
  imported location specified by :prop_tgt:`IMPORTED_LOCATION`.

* The :prop_tgt:`NO_SYSTEM_FROM_IMPORTED` target property is now supported
  on :ref:`Imported <Imported Targets>` :ref:`Interface Libraries`.

* New source file properties :prop_sf:`SKIP_AUTOMOC`, :prop_sf:`SKIP_AUTOUIC`,
  :prop_sf:`SKIP_AUTORCC`, and :prop_sf:`SKIP_AUTOGEN` were added to allow
  source files to be excluded from processing by :prop_tgt:`AUTOMOC`,
  :prop_tgt:`AUTOUIC`, and :prop_tgt:`AUTORCC` target properties.

* A :prop_sf:`VS_COPY_TO_OUT_DIR` source file property was added to
  tell :ref:`Visual Studio Generators` for VS 2010 and above whether
  or not a file should e copied to the output directory.

* A :prop_tgt:`VS_DEBUGGER_WORKING_DIRECTORY` target property was added
  to tell :ref:`Visual Studio Generators` for VS 2010 and above what
  debugger working directory should be set for the target.

* A :prop_tgt:`VS_DOTNET_REFERENCES_COPY_LOCAL` target property was added
  to specify whether to copy referenced assemblies to the output directory.

* A :prop_tgt:`VS_DOTNET_REFERENCE_<refname>` target property was added
  to tell :ref:`Visual Studio Generators` for VS 2010 and above to add
  a .NET reference with a given hint path.

* A :prop_sf:`VS_INCLUDE_IN_VSIX` source file property was added to
  tell :ref:`Visual Studio Generators` for VS 2010 and above whether
  to include the file in a Visual Studio extension package.

* A :prop_sf:`VS_RESOURCE_GENERATOR` source file property was added to
  give :ref:`Visual Studio Generators` for VS 2010 and above a setting
  for the resource generator (``C#`` only).

* A :prop_tgt:`VS_USER_PROPS` target property was added to tell
  :ref:`Visual Studio Generators` for VS 2010 and above to use a
  custom MSBuild user ``.props`` file.

* A :prop_gbl:`XCODE_EMIT_EFFECTIVE_PLATFORM_NAME` global property was
  added to tell the :generator:`Xcode` generator whether to emit the
  ``EFFECTIVE_PLATFORM_NAME`` variable.  This is useful when building
  with multiple SDKs like ``macosx`` and ``iphoneos`` in parallel.

* New :prop_tgt:`XCODE_PRODUCT_TYPE` and :prop_tgt:`XCODE_EXPLICIT_FILE_TYPE`
  target properties were created to tell the :generator:`Xcode` generator
  to use custom values of the corresponding attributes for a target in the
  generated Xcode project.

Modules
-------

* A :module:`CSharpUtilities` module was added to aid parameterization of
  Visual Studio C# targets.  It provides functions to allow automated
  setting of source file properties to support Windows Forms, WPF/XAML or
  other technologies as needed.

* The :module:`ExternalData` module learned to support multiple
  content links for one data file using different hashes, e.g.
  ``img.png.sha256`` and ``img.png.sha1``.  This allows objects
  to be fetched from sources indexed by different hash algorithms.

* The :module:`ExternalProject` module gained the ``GIT_PROGRESS`` option to
  force Git to show progress when cloning repositories.

* The :module:`ExternalProject` module gained a ``GIT_CONFIG`` option
  to pass ``--config`` options to Git when cloning repositories.

* The :module:`FeatureSummary` module :command:`feature_summary` command now
  accepts a new ``QUIET_ON_EMPTY`` option that suppresses the output when
  the list of packages that belong to the selected category is empty.

* The :module:`FeatureSummary` module :command:`add_feature_info` command
  now accepts lists of dependencies for deciding whether a feature is enabled
  or not.

* The package types accepted by the :module:`FeatureSummary` module can now
  be tweaked by changing the :variable:`FeatureSummary_PKG_TYPES`,
  :variable:`FeatureSummary_REQUIRED_PKG_TYPES` and
  :variable:`FeatureSummary_DEFAULT_PKG_TYPE` global properties.

* The :module:`FindOpenGL` module now provides imported targets
  ``OpenGL::GL`` and ``OpenGL::GLU`` when the libraries are found.

* The :module:`UseSWIG` module gained a ``swig_add_library`` command
  to give more flexibility over the old ``swig_add_module`` command.

* The :module:`UseSWIG` module ``swig_add_source_to_module`` command
  learned a new ``SWIG_OUTFILE_DIR`` option to control the output
  file location (``swig -o``).

* The :module:`WriteCompilerDetectionHeader` module gained the
  ``ALLOW_UNKNOWN_COMPILERS`` and ``ALLOW_UNKNOWN_COMPILER_VERSIONS`` options
  that allow creation of headers that will work also with unknown or old
  compilers by simply assuming they do not support any of the requested
  features.

CTest
-----

* The :command:`ctest_memcheck` command gained a ``DEFECT_COUNT <var>``
  option to capture the number of memory defects detected.

* The :command:`ctest_memcheck` command learned to read the location of
  suppressions files for sanitizers from the
  :variable:`CTEST_MEMORYCHECK_SUPPRESSIONS_FILE` variable.

* The :command:`ctest_memcheck` command learned to support ``LeakSanitizer``
  independently from ``AddressSanitizer``.

* The :command:`ctest_update` command ``CDASH_UPLOAD`` signature was taught
  to honor the ``RETRY_COUNT``, ``RETRY_DELAY``, and ``QUIET`` options.

CPack
-----

* The :module:`CPackIFWConfigureFile` module was added to define a new
  :command:`cpack_ifw_configure_file` command to configure file templates
  prepared in QtIFW/SDK/Creator style.

* The :module:`CPackIFW` module :command:`cpack_ifw_configure_component` and
  :command:`cpack_ifw_configure_component_group` commands gained a new
  ``DEFAULT``, ``VIRTUAL``, ``FORCED_INSTALLATION``, ``REQUIRES_ADMIN_RIGHTS``,
  ``DISPLAY_NAME``, ``UPDATE_TEXT``, ``DESCRIPTION``, ``RELEASE_DATE``,
  ``AUTO_DEPEND_ON`` and ``TRANSLATIONS`` options to more specific
  configuration.

* The :module:`CPackIFW` module :command:`cpack_ifw_configure_component`
  command gained a new ``DEPENDENCIES`` alias for ``DEPENDS`` option.

* The :module:`CPackIFW` module :command:`cpack_ifw_configure_component_group`
  command gained a new ``DEPENDS`` option. The ``DEPENDENCIES`` alias also
  added.

* The :module:`CPackIFW` module :command:`cpack_ifw_configure_component` and
  :command:`cpack_ifw_configure_component_group` commands ``PRIORITY``
  option now is deprecated and will be removed in a future version of CMake.
  Please use new ``SORTING_PRIORITY`` option instead.

* The :cpack_gen:`CPack IFW Generator` gained new
  :variable:`CPACK_IFW_PACKAGE_WATERMARK`,
  :variable:`CPACK_IFW_PACKAGE_BANNER`,
  :variable:`CPACK_IFW_PACKAGE_BACKGROUND`,
  :variable:`CPACK_IFW_PACKAGE_WIZARD_STYLE`,
  :variable:`CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH`,
  :variable:`CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT`, and
  :variable:`CPACK_IFW_PACKAGE_TITLE_COLOR`
  variables to customize a QtIFW installer look.

* The :cpack_gen:`CPack productbuild Generator` gained options to sign packages.
  See the variables :variable:`CPACK_PRODUCTBUILD_IDENTITY_NAME`,
  :variable:`CPACK_PRODUCTBUILD_KEYCHAIN_PATH`,
  :variable:`CPACK_PKGBUILD_IDENTITY_NAME`, and
  :variable:`CPACK_PKGBUILD_KEYCHAIN_PATH`.

* The :cpack_gen:`CPack RPM Generator` learned to omit tags that are not
  supported by provided ``rpmbuild`` tool. If unsupported tags are set they
  are ignored and a developer warning is printed out.

* The :cpack_gen:`CPack RPM Generator` learned to generate main component
  package which forces generation of a rpm for defined component without
  component suffix in filename and package name.
  See :variable:`CPACK_RPM_MAIN_COMPONENT` variable.

* The :cpack_gen:`CPack RPM Generator` learned to generate a single
  ``debuginfo`` package on demand even if components packaging is used.
  See :variable:`CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE` variable.

* The :cpack_gen:`CPack RPM Generator` learned to support
  multiple directives per file when using
  :variable:`CPACK_RPM_USER_FILELIST` variable.

Other
-----

* CMake functionality using cryptographic hashes now supports SHA-3 algorithms.

* A new generator expression ``$<IF:cond,true-value,false-value>`` was added.
  It resolves to the true-value if the condition is ``1`` and resolves to
  the false-value if the condition is ``0``.

Deprecated and Removed Features
===============================

* The :module:`FeatureSummary` module commands :command:`set_package_info`,
  :command:`set_feature_info`, :command:`print_enabled_features`, and
  :command:`print_disabled_features` are now deprecated.

* The :module:`UseSWIG` module ``swig_add_module`` command is now
  deprecated in favor of ``swig_add_library``.

Other Changes
=============

* If a command specified by the :prop_tgt:`<LANG>_CLANG_TIDY` target property
  returns non-zero at build time this is now treated as an error instead of
  silently ignored.

* The :command:`ctest_memcheck` command no longer automatically adds
  ``leak_check=1`` to the options used by ``AddressSanitizer``. The default
  behavior of ``AddressSanitizer`` is to run `LeakSanitizer` to check leaks
  unless ``leak_check=0``.

* The :command:`ctest_memcheck` command was fixed to correctly append extra
  sanitizer options read from the
  :variable:`CTEST_MEMORYCHECK_SANITIZER_OPTIONS` variable to the environment
  variables used internally by the sanitizers.

* The :module:`FeatureSummary` module :command:`set_package_properties`
  command no longer forces the package type to ``OPTIONAL`` when the type
  is not explicitly set.

* The :manual:`Compile Features <cmake-compile-features(7)>` functionality
  is now aware of features supported by Intel C++ compilers versions 12.1
  through 17.0 on UNIX and Windows platforms.

* Calls to the :module:`FindPkgConfig` module :command:`pkg_check_modules`
  command following a successful call learned to re-evaluate the cached values
  for a given prefix after changes to the parameters to the command for that
  prefix.

* When using :prop_tgt:`AUTOMOC` or :prop_tgt:`AUTOUIC`, generated
  ``moc_*``, ``*.moc`` and ``ui_*`` are placed in the
  ``<CMAKE_CURRENT_BINARY_DIR>/<TARGETNAME>_autogen/include`` directory which
  is automatically added to the target's :prop_tgt:`INCLUDE_DIRECTORIES`.
  It is therefore not necessary anymore to have
  :variable:`CMAKE_CURRENT_BINARY_DIR` in the target's
  :prop_tgt:`INCLUDE_DIRECTORIES`.

* The :generator:`Sublime Text 2` generator no longer runs the native
  build command (e.g. ``ninja`` or ``make``) with verbose build output
  enabled.

* The :command:`try_compile` command source file signature now
  honors the :variable:`CMAKE_WARN_DEPRECATED` variable value
  in the generated test project.

* The :ref:`Visual Studio Generators` for VS 2010 and above now place
  per-source file flags after target-wide flags when they are classified
  as raw flags with no project file setting (``AdditionalOptions``).
  This behavior is more consistent with the ordering of flags produced
  by other generators, and allows flags on more-specific properties
  (per-source) to override those on more general ones (per-target).

* The precompiled Windows binary MSI package provided on ``cmake.org`` now
  records the installation directory in the Windows Registry under the key
  ``HKLM\Software\Kitware\CMake`` with a value named ``InstallDir``.


code:
CMake 3.9 Release Notes
***********************

.. only:: html

  .. contents::

Changes made since CMake 3.8 include the following.

New Features
============

Languages
---------

* ``CUDA`` is now supported by the :ref:`Visual Studio Generators`
  for VS 2010 and above.  This complements the existing support by the
  :ref:`Makefile Generators` and the :generator:`Ninja` generator.
  CUDA 8.0.61 or higher is recommended due to known bugs in the VS
  integration by earlier versions.

* CMake is now aware of the :prop_tgt:`C++ standards <CXX_STANDARD>` and
  :prop_tgt:`C standards <C_STANDARD>` and their associated meta-features for
  the following :variable:`compiler ids <CMAKE_<LANG>_COMPILER_ID>`: ``Cray``,
  ``PGI``, and ``XL``.

Generators
----------

* :ref:`Visual Studio Generators` for VS 2010 and above learned to support
  the ``ASM_NASM`` language when ``nasm`` is installed.

* The :generator:`Xcode` generator learned to create Xcode schema files.
  This is an experimental feature and can be activated by setting the
  :variable:`CMAKE_XCODE_GENERATE_SCHEME` variable to a ``TRUE`` value.

Commands
--------

* The :command:`add_library` command ``IMPORTED`` option learned to support
  :ref:`Object Libraries`.

* The :command:`find_library` command learned to search ``libx32`` paths
  when the build targets the ``x32`` ABI.  See the
  :prop_gbl:`FIND_LIBRARY_USE_LIBX32_PATHS` global property.

* The :command:`include_external_msproject` command learned to use
  the :prop_tgt:`MAP_IMPORTED_CONFIG_<CONFIG>` target property
  to map current configurations to the external configurations.

* The :command:`install(TARGETS)` command learned a new ``OBJECTS`` option to
  specify where to install :ref:`Object Libraries`.

* The :command:`install(EXPORT)` command learned how to export
  :ref:`Object Libraries`.

* The :command:`project` command learned an optional ``DESCRIPTION``
  parameter to set the :variable:`PROJECT_DESCRIPTION` variable.

* The :command:`separate_arguments` command gained a ``NATIVE_COMMAND`` mode
  that performs argument separation depending on the host operating system.

Variables
---------

* A :variable:`CMAKE_ANDROID_NDK_DEPRECATED_HEADERS` variable was added
  for use when :ref:`Cross Compiling for Android with the NDK` to request
  use of the deprecated headers even when unified headers are available.
  The default is now to use unified headers if available.

* A :variable:`CMAKE_AUTOMOC_DEPEND_FILTERS` variable was introduced to
  allow :variable:`CMAKE_AUTOMOC` to extract additional dependency file names
  for ``moc`` from the contents of source files.

* A :variable:`CMAKE_AUTOUIC_SEARCH_PATHS` variable was introduced to
  allow :variable:`CMAKE_AUTOUIC` to search for ``foo.ui`` in more
  places than the vicinity of the file including ``ui_foo.h``.

* A :variable:`CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX` variable was added to
  tell the :command:`find_library` command to search in a ``lib<suffix>``
  directory before each ``lib`` directory that would normally be searched.

* A :variable:`CMAKE_INTERPROCEDURAL_OPTIMIZATION` variable was added to
  initialize the :prop_tgt:`INTERPROCEDURAL_OPTIMIZATION` property on all
  targets.

* A :variable:`CMAKE_<LANG>_COMPILER_AR` variable was added to hold
  the path to the GCC/Clang wrapper of ``ar``.

* A :variable:`CMAKE_<LANG>_COMPILER_RANLIB` variable was added to hold
  the path to the GCC/Clang wrapper of ``ranlib``.

* The :variable:`CMAKE_SYSROOT_COMPILE` and :variable:`CMAKE_SYSROOT_LINK`
  variables were added to use separate sysroots for compiling and linking.

Properties
----------

* A new :prop_tgt:`AUTOGEN_BUILD_DIR` target property was introduced to set
  a custom output directory for :prop_tgt:`AUTOMOC`, :prop_tgt:`AUTOUIC`,
  and :prop_tgt:`AUTORCC`.

* A new :prop_tgt:`AUTOMOC_DEPEND_FILTERS` target property was introduced to
  allow :prop_tgt:`AUTOMOC` to extract additional dependency file names
  for ``moc`` from the contents of source files.

* A new :prop_tgt:`AUTOUIC_SEARCH_PATHS` target property was introduced to
  allow :prop_tgt:`AUTOUIC` to search for ``foo.ui`` in more
  places than the vicinity of the file including ``ui_foo.h``.

* Global properties :prop_gbl:`AUTOGEN_SOURCE_GROUP`,
  :prop_gbl:`AUTOMOC_SOURCE_GROUP` and
  :prop_gbl:`AUTORCC_SOURCE_GROUP` were
  introduced to allow files generated by :prop_tgt:`AUTOMOC` or
  :prop_tgt:`AUTORCC` to be placed in a :command:`source_group`.

* A :prop_tgt:`BUILD_WITH_INSTALL_NAME_DIR` target property and corresponding
  :variable:`CMAKE_BUILD_WITH_INSTALL_NAME_DIR` variable were added to
  control whether to use the :prop_tgt:`INSTALL_NAME_DIR` target property
  value for binaries in the build tree.  This is for macOS ``install_name``
  as :prop_tgt:`BUILD_WITH_INSTALL_RPATH` is for ``RPATH``.

* A :prop_tgt:`CUDA_PTX_COMPILATION` target property was added to
  :ref:`Object Libraries` to support compiling to ``.ptx`` files
  instead of host object files.

* A :prop_gbl:`GENERATOR_IS_MULTI_CONFIG` global property was
  added to determine whether the current generator is a multi-configuration
  generator (such as :ref:`Visual Studio Generators` or :generator:`Xcode`).

* The :prop_tgt:`INTERPROCEDURAL_OPTIMIZATION` target property is now enforced
  when enabled.  CMake will add IPO flags unconditionally or produce an error
  if it does not know the flags for the current compiler.  The project is now
  responsible to use the :module:`CheckIPOSupported` module to check for IPO
  support before enabling the target property.  See policy :policy:`CMP0069`.

* The :prop_tgt:`WINDOWS_EXPORT_ALL_SYMBOLS` target property may now
  be used in combination with explicit ``.def`` files in order to
  export all symbols from the object files within a target plus
  an explicit list of symbols that the linker finds in dependencies
  (e.g. ``msvcrt.lib``).

Modules
-------

* A :module:`CheckIPOSupported` module was added to help projects
  check whether interprocedural optimization (IPO) is supported by
  the current toolchain and CMake version.

* The :module:`CMakeFindDependencyMacro` module ``find_dependency`` macro
  now forwards all arguments to the underlying :command:`find_package`
  call.  Existing uses will continue to function as before, but callers can
  now access the full suite of arguments that :command:`find_package` accepts.

* The :module:`FeatureSummary` module :command:`feature_summary` command now
  accepts the new ``DEFAULT_DESCRIPTION`` option that will print the default
  title for the selected package type.

* The :module:`FeatureSummary` module gained a new
  :variable:`FeatureSummary_<TYPE>_DESCRIPTION` variable that can be defined
  for each ``<TYPE>`` to replace the type name with the specified string
  whenever the package type is used in an output string by the module.

* The :module:`FindDoxygen` module learned to control Doxygen behavior using
  CMake variables and generate documentation via the newly added
  :command:`doxygen_add_docs` function. The Doxygen input file (``Doxyfile``)
  is automatically generated and doxygen is run as part of a custom target.
  Additional components can be specified to find optional tools: ``dot``,
  ``mscgen`` and ``dia``.

* The :module:`FindMPI` module now provides imported targets.

* The :module:`FindProtobuf` module :command:`protobuf_generate_cpp`
  command gained an ``EXPORT_MACRO`` option to specify the name of
  a DLL export markup macro.

* The :module:`FindProtobuf` module now supports usage of static libraries
  for Unix via a new ``Protobuf_USE_STATIC_LIBS`` input variable.

* The :module:`FindProtobuf` module now provides imported targets
  when the libraries are found.

* A new :module:`GoogleTest` module was added to provide the
  :command:`gtest_add_tests` function independently of the :module:`FindGTest`
  module. The function was also updated to support keyword arguments, with
  functionality expanded to allow a test name prefix and suffix to be
  specified, the dependency on the source files to be optional and the list of
  discovered test cases to be returned to the caller.

CTest
-----

* The :command:`ctest_submit` command gained a ``HTTPHEADER`` option
  to specify custom headers to send during submission.

* The :manual:`ctest(1)` executable gained new options which allow the
  developer to disable automatically adding tests to the test set to satisfy
  fixture dependencies. ``-FS`` prevents adding setup tests for fixtures
  matching the provided regular expression, ``-FC`` prevents adding cleanup
  tests for matching fixtures and ``-FA`` prevents adding any test for matching
  fixtures.

* A :prop_test:`DISABLED` test property was added to mark tests that
  are configured but explicitly disabled so they do not run.

CPack
-----

* The :cpack_gen:`CPack Archive Generator` learned to modify the filename
  per-component.  See the :variable:`CPACK_ARCHIVE_FILE_NAME` variable and
  its per-component version :variable:`CPACK_ARCHIVE_<component>_FILE_NAME`.

* The :module:`CPackComponent` module :command:`cpack_add_component` command
  gained a new ``PLIST <filename>`` option to specify the ``pkgbuild``
  ``--component-plist`` argument when using the
  :module:`productbuild <CPackProductBuild>` generator.

* The :module:`CPackIFW` module :command:`cpack_ifw_configure_component` and
  :command:`cpack_ifw_configure_component_group` commands gained
  internationalization support for ``DISPLAY_NAME`` and ``DESCRIPTION``
  options.

* The :cpack_gen:`CPack IFW Generator` learned the new hint
  :variable:`CPACK_IFW_ROOT` variable for finding the QtIFW tool suite
  installed in a non-standard place.

* The :cpack_gen:`CPack productbuild Generator` gained a new
  :variable:`CPACK_PRODUCTBUILD_RESOURCES_DIR` variable to
  specify resources to be copied into the ``Resources``
  directory.

* The :cpack_gen:`CPack RPM Generator` learned to modify the ``debuginfo``
  package name.  See the :variable:`CPACK_RPM_DEBUGINFO_FILE_NAME` variable.

* The :cpack_gen:`CPack WIX Generator` patching system now has the
  ability to set additional attributes.  This can be done by specifying
  attributes with the ``CPackWiXFragment`` XML tag after the ``Id`` attribute.
  See the :variable:`CPACK_WIX_PATCH_FILE` variable.

* The :cpack_gen:`CPack WIX Generator` implemented a new
  :variable:`CPACK_WIX_ROOT_FOLDER_ID` variable which allows
  using a custom root folder ID instead of the default
  ``ProgramFilesFolder`` / ``ProgramFiles64Folder``.

Other
-----

* Interprocedural optimization (IPO) is now supported for GNU and Clang
  compilers using link time optimization (LTO) flags.  See the
  :prop_tgt:`INTERPROCEDURAL_OPTIMIZATION` target property and
  :module:`CheckIPOSupported` module.

* The ``TARGET_OBJECTS``
  :manual:`generator expression <cmake-generator-expressions(7)>`
  is now supported by the :command:`add_custom_command` and
  :command:`file(GENERATE)` commands.

* Two new informational generator expressions to retrieve Apple Bundle
  directories have been added. The first one :genex:`$<TARGET_BUNDLE_DIR:tgt>`
  outputs the full path to the Bundle directory, the other one
  :genex:`$<TARGET_BUNDLE_CONTENT_DIR:tgt>` outputs the full path to the
  ``Contents`` directory of macOS Bundles and App Bundles. For all other
  bundle types and SDKs it is identical with :genex:`$<TARGET_BUNDLE_DIR:tgt>`.
  The new expressions are helpful to query Bundle locations independent of
  the different Bundle types and layouts on macOS and iOS.

Deprecated and Removed Features
===============================

* An explicit deprecation diagnostic was added for policies ``CMP0036``
  and below.  The :manual:`cmake-policies(7)` manual explains that the
  OLD behaviors of all policies are deprecated and that projects should
  always port to the NEW behaviors as soon as possible.

* The :generator:`Visual Studio 8 2005` generator is now deprecated
  and will be removed in a future version of CMake.

* The :generator:`Visual Studio 7 .NET 2003` generator has been removed.

* The :generator:`Xcode` generator dropped support for Xcode versions
  older than 3.

* The :module:`FindDoxygen` module has deprecated several variables.

* The version of curl bundled with CMake no longer accepts URLs of the form
  ``file://c:/...`` on Windows due to a change in upstream curl 7.52.  Use
  the form ``file:///c:/...`` instead to work on all versions.

Other Changes
=============

* When using :prop_tgt:`AUTOMOC`, CMake now scans for the presence of the
  ``Q_PLUGIN_METADATA`` macro and reruns moc when the file from the
  macro's ``FILE`` argument changes.

* When :prop_tgt:`AUTOMOC` detects an include statement of the form
  ``#include "moc_<basename>.cpp"`` the search for the respective header file
  now looks in the :prop_tgt:`INCLUDE_DIRECTORIES` of the target as well.

* When running tests, CTest learned to treat skipped tests (using the
  :prop_test:`SKIP_RETURN_CODE` property) the same as tests with the new
  :prop_test:`DISABLED` property. Due to this change, CTest will not indicate
  failure when all tests are either skipped or pass.

* The :generator:`Ninja` generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's target
  depends and no longer depends on the libraries themselves.  Source files
  in dependent targets may now compile without waiting for their targets'
  dependencies to link.

* On macOS, ``RPATH`` settings such as :prop_tgt:`BUILD_WITH_INSTALL_RPATH`
  no longer affect the ``install_name`` field.  See policy :policy:`CMP0068`.

* The :generator:`Visual Studio 14 2015` generator has been taught about
  a change to the ``v140`` toolset made by a VS 2015 update.  VS changed
  the set of values it understands for the ``GenerateDebugInformation``
  linker setting that produces the ``-DEBUG`` linker flag variants.

Updates
=======

Changes made since CMake 3.9.0 include the following.

3.9.1
-----

* The ``find_`` command ``PACKAGE_ROOT`` search path group added by
  CMake 3.9.0 has been removed for the 3.9 series due to regressions
  caused by new use of ``<PackageName>_ROOT`` variables.  The behavior
  may be re-introduced in the future in a more-compatible way.

3.9.2
-----

* On macOS, the default application bundle ``Info.plist`` file no longer
  enables Hi-DPI support as it did in 3.9.0 and 3.9.1.  The change had
  to be reverted because it broke iOS applications.

* The Xcode generator no longer adds "outputPaths" to custom script
  build phases as it did in 3.9.0 and 3.9.1.  This was added in an
  attempt to support Xcode 9's new build system, but broke incremental
  rebuilds for both the old and new Xcode build systems.

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
ANDROID
-------

.. versionadded:: 3.7

Set to ``1`` when the target system (:variable:`CMAKE_SYSTEM_NAME`) is
``Android``.


code:
APPLE
-----

Set to ``True`` when the target system is an Apple platform
(macOS, iOS, tvOS, visionOS or watchOS).


code:
BORLAND
-------

``True`` if the Borland compiler is being used.

This is set to ``true`` if the Borland compiler is being used.


code:
BSD
---

.. versionadded:: 3.25

Set to a string value when the target system is BSD. This value can be one of
the following: DragonFlyBSD, FreeBSD, OpenBSD, or NetBSD.


code:
BUILD_SHARED_LIBS
-----------------

Tell :command:`add_library` to default to ``SHARED`` libraries,
instead of ``STATIC`` libraries, when called with no explicit library type.

Calls to :command:`add_library` without any explicit library type check
the current ``BUILD_SHARED_LIBS`` variable value.  If it is true, then the
default library type is ``SHARED``.  Otherwise, the default is ``STATIC``.

For example, the code:

.. code-block:: cmake

  add_library(example ${sources})

behaves as if written

.. code-block:: cmake

  if(BUILD_SHARED_LIBS)
    add_library(example SHARED ${sources})
  else()
    add_library(example STATIC ${sources})
  endif()

CMake does not define ``BUILD_SHARED_LIBS`` by default, but projects
often create a cache entry for it using the :command:`option` command:

.. code-block:: cmake

  option(BUILD_SHARED_LIBS "Build using shared libraries" ON)

This provides a switch that users can control, e.g., with :option:`cmake -D`.
If adding such an option to the project, do so in the top level
``CMakeLists.txt`` file, before any :command:`add_library` calls.
Note that if bringing external dependencies directly into the build, such as
with :module:`FetchContent` or a direct call to :command:`add_subdirectory`,
and one of those dependencies has such a call to
:command:`option(BUILD_SHARED_LIBS ...) <option>`, the top level project must
also call :command:`option(BUILD_SHARED_LIBS ...) <option>` before bringing in
its dependencies.  Failure to do so can lead to different behavior between the
first and subsequent CMake runs.


code:
CACHE
-----

.. versionadded:: 3.13

Operator to read cache variables.

Use the syntax ``$CACHE{VAR}`` to read cache entry ``VAR``.
See the :ref:`cmake-language(7) variables <CMake Language Variables>`
documentation for more complete documentation of the interaction of
normal variables and cache entries.

When evaluating :ref:`Variable References` of the form ``${VAR}``,
CMake first searches for a normal variable with that name, and if not
found CMake will search for a cache entry with that name.
The ``$CACHE{VAR}`` syntax can be used to do direct cache lookup and
ignore any existing normal variable.

See the :command:`set` and :command:`unset` commands to see how to
write or remove cache variables.


code:
CMAKE_ABSOLUTE_DESTINATION_FILES
--------------------------------

List of files which have been installed using an ``ABSOLUTE DESTINATION`` path.

This variable is defined by CMake-generated ``cmake_install.cmake``
scripts.  It can be used (read-only) by programs or scripts that
source those install scripts.  This is used by some CPack generators
(e.g.  RPM).


code:
CMAKE_ADD_CUSTOM_COMMAND_DEPENDS_EXPLICIT_ONLY
----------------------------------------------

.. versionadded:: 3.27

Whether to enable the ``DEPENDS_EXPLICIT_ONLY`` option by default in
:command:`add_custom_command`.

This variable affects the default behavior of the :command:`add_custom_command`
command.  Setting this variable to ``ON`` is equivalent to using the
``DEPENDS_EXPLICIT_ONLY`` option in all uses of that command.

See also :variable:`CMAKE_OPTIMIZE_DEPENDENCIES`.


code:
CMAKE_ADSP_ROOT
---------------

.. versionadded:: 3.24

When :ref:`Cross Compiling for ADSP SHARC/Blackfin`,
this variable holds the absolute path to the latest CCES or VDSP++ install.
The directory is expected to contain the ``cc21k.exe`` and ``ccblkfn.exe`` compilers.
This will be set automatically if a default install of CCES or VDSP++ can be found.

See also the :envvar:`ADSP_ROOT` environment variable.


code:
CMAKE_AIX_EXPORT_ALL_SYMBOLS
----------------------------

.. versionadded:: 3.17

Default value for :prop_tgt:`AIX_EXPORT_ALL_SYMBOLS` target property.
This variable is used to initialize the property on each target as it is
created.


code:
CMAKE_ANDROID_ANT_ADDITIONAL_OPTIONS
------------------------------------

.. versionadded:: 3.4

Default value for the :prop_tgt:`ANDROID_ANT_ADDITIONAL_OPTIONS` target property.
See that target property for additional information.


code:
CMAKE_ANDROID_API
-----------------

.. versionadded:: 3.1

When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
Edition`, this variable may be set to specify the default value for the
:prop_tgt:`ANDROID_API` target property.  See that target property for
additional information.

When :ref:`Cross Compiling for Android`, the :variable:`CMAKE_SYSTEM_VERSION`
variable represents the Android API version number targeted.  For historical
reasons, if a toolchain file sets ``CMAKE_ANDROID_API``, but not
``CMAKE_SYSTEM_VERSION``, the latter will be initialized using the former.


code:
CMAKE_ANDROID_API_MIN
---------------------

.. versionadded:: 3.2

Default value for the :prop_tgt:`ANDROID_API_MIN` target property.
See that target property for additional information.


code:
CMAKE_ANDROID_ARCH
------------------

.. versionadded:: 3.4

When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
Edition`, this variable may be set to specify the default value for the
:prop_tgt:`ANDROID_ARCH` target property.  See that target property for
additional information.

Otherwise, when :ref:`Cross Compiling for Android`, this variable provides
the name of the Android architecture corresponding to the value of the
:variable:`CMAKE_ANDROID_ARCH_ABI` variable.  The architecture name
may be one of:

* ``arm``
* ``arm64``
* ``mips``
* ``mips64``
* ``x86``
* ``x86_64``


code:
CMAKE_ANDROID_ARCH_ABI
----------------------

.. versionadded:: 3.7

When :ref:`Cross Compiling for Android`, this variable specifies the
target architecture and ABI to be used.  Valid values are:

* ``arm64-v8a``
* ``armeabi-v7a``
* ``armeabi-v6``
* ``armeabi``
* ``mips``
* ``mips64``
* ``x86``
* ``x86_64``

See also the :variable:`CMAKE_ANDROID_ARM_MODE` and
:variable:`CMAKE_ANDROID_ARM_NEON` variables.


code:
CMAKE_ANDROID_ARM_MODE
----------------------

.. versionadded:: 3.7

When :ref:`Cross Compiling for Android` and :variable:`CMAKE_ANDROID_ARCH_ABI`
is set to one of the ``armeabi`` architectures, set ``CMAKE_ANDROID_ARM_MODE``
to ``ON`` to target 32-bit ARM processors (``-marm``).  Otherwise, the
default is to target the 16-bit Thumb processors (``-mthumb``).


code:
CMAKE_ANDROID_ARM_NEON
----------------------

.. versionadded:: 3.7

When :ref:`Cross Compiling for Android` and :variable:`CMAKE_ANDROID_ARCH_ABI`
is set to ``armeabi-v7a`` set ``CMAKE_ANDROID_ARM_NEON`` to ``ON`` to target
ARM NEON devices.


code:
CMAKE_ANDROID_ASSETS_DIRECTORIES
--------------------------------

.. versionadded:: 3.4

Default value for the :prop_tgt:`ANDROID_ASSETS_DIRECTORIES` target property.
See that target property for additional information.


code:
CMAKE_ANDROID_EXCEPTIONS
------------------------

.. versionadded:: 3.20

When :ref:`Cross Compiling for Android with the NDK`, this variable may be set
to specify whether exceptions are enabled.


code:
CMAKE_ANDROID_GUI
-----------------

.. versionadded:: 3.1

Default value for the :prop_tgt:`ANDROID_GUI` target property of
executables.  See that target property for additional information.


code:
CMAKE_ANDROID_JAR_DEPENDENCIES
------------------------------

.. versionadded:: 3.4

Default value for the :prop_tgt:`ANDROID_JAR_DEPENDENCIES` target property.
See that target property for additional information.


code:
CMAKE_ANDROID_JAR_DIRECTORIES
-----------------------------

.. versionadded:: 3.4

Default value for the :prop_tgt:`ANDROID_JAR_DIRECTORIES` target property.
See that target property for additional information.


code:
CMAKE_ANDROID_JAVA_SOURCE_DIR
-----------------------------

.. versionadded:: 3.4

Default value for the :prop_tgt:`ANDROID_JAVA_SOURCE_DIR` target property.
See that target property for additional information.


code:
CMAKE_ANDROID_NATIVE_LIB_DEPENDENCIES
-------------------------------------

.. versionadded:: 3.4

Default value for the :prop_tgt:`ANDROID_NATIVE_LIB_DEPENDENCIES` target
property.  See that target property for additional information.


code:
CMAKE_ANDROID_NATIVE_LIB_DIRECTORIES
------------------------------------

.. versionadded:: 3.4

Default value for the :prop_tgt:`ANDROID_NATIVE_LIB_DIRECTORIES` target
property.  See that target property for additional information.


code:
CMAKE_ANDROID_NDK
-----------------

.. versionadded:: 3.7

When :ref:`Cross Compiling for Android with the NDK`, this variable holds
the absolute path to the root directory of the NDK.  The directory must
contain a ``platforms`` subdirectory holding the ``android-<api>``
directories.


code:
CMAKE_ANDROID_NDK_DEPRECATED_HEADERS
------------------------------------

.. versionadded:: 3.9

When :ref:`Cross Compiling for Android with the NDK`, this variable
may be set to specify whether to use the deprecated per-api-level
headers instead of the unified headers.

If not specified, the default will be *false* if using a NDK version
that provides the unified headers and *true* otherwise.


code:
CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG
------------------------------------

.. versionadded:: 3.7.1

When :ref:`Cross Compiling for Android with the NDK`, this variable
provides the NDK's "host tag" used to construct the path to prebuilt
toolchains that run on the host.


code:
CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION
-----------------------------------

.. versionadded:: 3.7

When :ref:`Cross Compiling for Android with the NDK`, this variable
may be set to specify the version of the toolchain to be used
as the compiler.

On NDK r19 or above, this variable must be unset or set to ``clang``.

On NDK r18 or below, this variable must be set to one of these forms:

* ``<major>.<minor>``: GCC of specified version
* ``clang<major>.<minor>``: Clang of specified version
* ``clang``: Clang of most recent available version

A toolchain of the requested version will be selected automatically to
match the ABI named in the :variable:`CMAKE_ANDROID_ARCH_ABI` variable.

If not specified, the default will be a value that selects the latest
available GCC toolchain.


code:
CMAKE_ANDROID_NDK_VERSION
-------------------------

.. versionadded:: 3.20

When :ref:`Cross Compiling for Android with the NDK` and using an
Android NDK version 11 or higher, this variable is provided by
CMake to report the NDK version number.


code:
CMAKE_ANDROID_PROCESS_MAX
-------------------------

.. versionadded:: 3.4

Default value for the :prop_tgt:`ANDROID_PROCESS_MAX` target property.
See that target property for additional information.


code:
CMAKE_ANDROID_PROGUARD
----------------------

.. versionadded:: 3.4

Default value for the :prop_tgt:`ANDROID_PROGUARD` target property.
See that target property for additional information.


code:
CMAKE_ANDROID_PROGUARD_CONFIG_PATH
----------------------------------

.. versionadded:: 3.4

Default value for the :prop_tgt:`ANDROID_PROGUARD_CONFIG_PATH` target property.
See that target property for additional information.


code:
CMAKE_ANDROID_RTTI
------------------

.. versionadded:: 3.20

When :ref:`Cross Compiling for Android with the NDK`, this variable may be set
to specify whether RTTI is enabled.


code:
CMAKE_ANDROID_SECURE_PROPS_PATH
-------------------------------

.. versionadded:: 3.4

Default value for the :prop_tgt:`ANDROID_SECURE_PROPS_PATH` target property.
See that target property for additional information.


code:
CMAKE_ANDROID_SKIP_ANT_STEP
---------------------------

.. versionadded:: 3.4

Default value for the :prop_tgt:`ANDROID_SKIP_ANT_STEP` target property.
See that target property for additional information.


code:
CMAKE_ANDROID_STANDALONE_TOOLCHAIN
----------------------------------

.. versionadded:: 3.7

When :ref:`Cross Compiling for Android with a Standalone Toolchain`, this
variable holds the absolute path to the root directory of the toolchain.
The specified directory must contain a ``sysroot`` subdirectory.


code:
CMAKE_ANDROID_STL_TYPE
----------------------

.. versionadded:: 3.4

When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
Edition`, this variable may be set to specify the default value for the
:prop_tgt:`ANDROID_STL_TYPE` target property.  See that target property
for additional information.

When :ref:`Cross Compiling for Android with the NDK`, this variable may be
set to specify the STL variant to be used.  The value may be one of:

``none``
  No C++ Support
``system``
  Minimal C++ without STL
``gabi++_static``
  GAbi++ Static
``gabi++_shared``
  GAbi++ Shared
``gnustl_static``
  GNU libstdc++ Static
``gnustl_shared``
  GNU libstdc++ Shared
``c++_static``
  LLVM libc++ Static
``c++_shared``
  LLVM libc++ Shared
``stlport_static``
  STLport Static
``stlport_shared``
  STLport Shared

The default value is ``gnustl_static`` on NDK versions that provide it
and otherwise ``c++_static``.  Note that this default differs from
the native NDK build system because CMake may be used to build projects for
Android that are not natively implemented for it and use the C++ standard
library.


code:
CMAKE_APPBUNDLE_PATH
--------------------

:ref:`Semicolon-separated list <CMake Language Lists>` of directories specifying a search path
for macOS application bundles used by the :command:`find_program`, and
:command:`find_package` commands.

There is also an environment variable :envvar:`CMAKE_APPBUNDLE_PATH`, which is used
as an additional list of search directories.


code:
CMAKE_APPLE_SILICON_PROCESSOR
-----------------------------

.. versionadded:: 3.19.2

On Apple Silicon hosts running macOS, set this variable to tell
CMake what architecture to use for :variable:`CMAKE_HOST_SYSTEM_PROCESSOR`.
The value must be either ``arm64`` or ``x86_64``.

The value of this variable should never be modified by project code.
It is meant to be set as a cache entry provided by the user,
e.g. via ``-DCMAKE_APPLE_SILICON_PROCESSOR=...``.

See also the :envvar:`CMAKE_APPLE_SILICON_PROCESSOR` environment variable.


code:
CMAKE_AR
--------

Name of archiving tool for static libraries.

This specifies the name of the program that creates archive or static
libraries.


code:
CMAKE_ARCHIVE_OUTPUT_DIRECTORY
------------------------------

Where to put all the :ref:`ARCHIVE <Archive Output Artifacts>`
target files when built.

This variable is used to initialize the :prop_tgt:`ARCHIVE_OUTPUT_DIRECTORY`
property on all the targets.  See that target property for additional
information.


code:
CMAKE_ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>
---------------------------------------

.. versionadded:: 3.3

Where to put all the :ref:`ARCHIVE <Archive Output Artifacts>`
target files when built for a specific configuration.

This variable is used to initialize the
:prop_tgt:`ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>` property on all the targets.
See that target property for additional information.


code:
CMAKE_ARGC
----------

Number of command line arguments passed to CMake in script mode.

When run in :ref:`-P <Script Processing Mode>` script mode, CMake sets this
variable to the number of command line arguments.  See also
:variable:`CMAKE_ARGV0`, ``1``, ``2`` ...


code:
CMAKE_ARGV0
-----------

Command line argument passed to CMake in script mode.

When run in :ref:`-P <Script Processing Mode>` script mode, CMake sets this
variable to the first command line argument.  It then also sets ``CMAKE_ARGV1``,
``CMAKE_ARGV2``, ... and so on, up to the number of command line arguments
given.  See also :variable:`CMAKE_ARGC`.


code:
CMAKE_AUTOGEN_BETTER_GRAPH_MULTI_CONFIG
---------------------------------------

.. versionadded:: 3.29

This variable is used to initialize the
:prop_tgt:`AUTOGEN_BETTER_GRAPH_MULTI_CONFIG` property on all targets as they
are created.  See that target property for additional information.

By default ``CMAKE_AUTOGEN_BETTER_GRAPH_MULTI_CONFIG`` is unset.


code:
CMAKE_AUTOGEN_COMMAND_LINE_LENGTH_MAX
-------------------------------------

.. versionadded:: 3.29

Command line length limit for autogen targets, i.e. ``moc`` or ``uic``,
that triggers the use of response files on Windows instead of passing all
arguments to the command line.

By default ``CMAKE_AUTOGEN_COMMAND_LINE_LENGTH_MAX`` is unset.


code:
CMAKE_AUTOGEN_ORIGIN_DEPENDS
----------------------------

.. versionadded:: 3.14

Switch for forwarding origin target dependencies to the corresponding
:ref:`<ORIGIN>_autogen` targets.

  .. note::

    If Qt 5.15 or later is used and the generator is either :generator:`Ninja`
    or :ref:`Makefile Generators`, additional target dependencies are added to
    the :ref:`<ORIGIN>_autogen_timestamp_deps` target instead of the
    :ref:`<ORIGIN>_autogen` target.

This variable is used to initialize the :prop_tgt:`AUTOGEN_ORIGIN_DEPENDS`
property on all the targets.  See that target property for additional
information.

By default ``CMAKE_AUTOGEN_ORIGIN_DEPENDS`` is ``ON``.


code:
CMAKE_AUTOGEN_PARALLEL
----------------------

.. versionadded:: 3.11

Number of parallel ``moc`` or ``uic`` processes to start when using
:prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC`.

This variable is used to initialize the :prop_tgt:`AUTOGEN_PARALLEL` property
on all the targets.  See that target property for additional information.

By default ``CMAKE_AUTOGEN_PARALLEL`` is unset.


code:
CMAKE_AUTOGEN_USE_SYSTEM_INCLUDE
--------------------------------

.. versionadded:: 3.27

This variable is used to initialize the :prop_tgt:`AUTOGEN_USE_SYSTEM_INCLUDE`
property on all targets as they are created.  See that target property for
additional information.

By default ``CMAKE_AUTOGEN_USE_SYSTEM_INCLUDE`` is unset.


code:
CMAKE_AUTOGEN_VERBOSE
---------------------

.. versionadded:: 3.13

Sets the verbosity of :prop_tgt:`AUTOMOC`, :prop_tgt:`AUTOUIC` and
:prop_tgt:`AUTORCC`.  A positive integer value or a true boolean value
lets the ``AUTO*`` generators output additional processing information.

Setting ``CMAKE_AUTOGEN_VERBOSE`` has the same effect
as setting the ``VERBOSE`` environment variable during
generation (e.g. by calling ``make VERBOSE=1``).
The extra verbosity is limited to the ``AUTO*`` generators though.

By default ``CMAKE_AUTOGEN_VERBOSE`` is unset.


code:
CMAKE_AUTOMOC
-------------

Whether to handle ``moc`` automatically for Qt targets.

This variable is used to initialize the :prop_tgt:`AUTOMOC` property on all the
targets.  See that target property for additional information.


code:
CMAKE_AUTOMOC_COMPILER_PREDEFINES
---------------------------------

.. versionadded:: 3.10

This variable is used to initialize the :prop_tgt:`AUTOMOC_COMPILER_PREDEFINES`
property on all the targets. See that target property for additional
information.

By default it is ON.


code:
CMAKE_AUTOMOC_DEPEND_FILTERS
----------------------------

.. versionadded:: 3.9

Filter definitions used by :variable:`CMAKE_AUTOMOC`
to extract file names from source code as additional dependencies
for the ``moc`` file.

This variable is used to initialize the :prop_tgt:`AUTOMOC_DEPEND_FILTERS`
property on all the targets. See that target property for additional
information.

By default it is empty.


code:
CMAKE_AUTOMOC_EXECUTABLE
------------------------

.. versionadded:: 3.27

This variable is used to initialize the :prop_tgt:`AUTOMOC_EXECUTABLE`
property on all the targets. See that target property for additional
information.

By default it is empty.


code:
CMAKE_AUTOMOC_MACRO_NAMES
----------------------------

.. versionadded:: 3.10

:ref:`Semicolon-separated list <CMake Language Lists>` list of macro names used by
:variable:`CMAKE_AUTOMOC` to determine if a C++ file needs to be
processed by ``moc``.

This variable is used to initialize the :prop_tgt:`AUTOMOC_MACRO_NAMES`
property on all the targets. See that target property for additional
information.

The default value is ``Q_OBJECT;Q_GADGET;Q_NAMESPACE;Q_NAMESPACE_EXPORT``.

Example
^^^^^^^
Let CMake know that source files that contain ``CUSTOM_MACRO`` must be ``moc``
processed as well::

  set(CMAKE_AUTOMOC ON)
  list(APPEND CMAKE_AUTOMOC_MACRO_NAMES "CUSTOM_MACRO")


code:
CMAKE_AUTOMOC_MOC_OPTIONS
-------------------------

Additional options for ``moc`` when using :variable:`CMAKE_AUTOMOC`.

This variable is used to initialize the :prop_tgt:`AUTOMOC_MOC_OPTIONS` property
on all the targets.  See that target property for additional information.


code:
CMAKE_AUTOMOC_PATH_PREFIX
-------------------------

.. versionadded:: 3.16

Whether to generate the ``-p`` path prefix option for ``moc`` on
:prop_tgt:`AUTOMOC` enabled Qt targets.

This variable is used to initialize the :prop_tgt:`AUTOMOC_PATH_PREFIX`
property on all the targets.  See that target property for additional
information.

The default value is ``OFF``.


code:
CMAKE_AUTOMOC_RELAXED_MODE
--------------------------

.. deprecated:: 3.15

Switch between strict and relaxed automoc mode.

By default, :prop_tgt:`AUTOMOC` behaves exactly as described in the
documentation of the :prop_tgt:`AUTOMOC` target property.  When set to
``TRUE``, it accepts more input and tries to find the correct input file for
``moc`` even if it differs from the documented behavior.  In this mode it
e.g.  also checks whether a header file is intended to be processed by moc
when a ``"foo.moc"`` file has been included.

Relaxed mode has to be enabled for KDE4 compatibility.


code:
CMAKE_AUTORCC
-------------

Whether to handle ``rcc`` automatically for Qt targets.

This variable is used to initialize the :prop_tgt:`AUTORCC` property on all
the targets.  See that target property for additional information.


code:
CMAKE_AUTORCC_EXECUTABLE
------------------------

.. versionadded:: 3.27

This variable is used to initialize the :prop_tgt:`AUTORCC_EXECUTABLE`
property on all the targets. See that target property for additional
information.

By default it is empty.


code:
CMAKE_AUTORCC_OPTIONS
---------------------

Additional options for ``rcc`` when using :variable:`CMAKE_AUTORCC`.

This variable is used to initialize the :prop_tgt:`AUTORCC_OPTIONS` property on
all the targets.  See that target property for additional information.

EXAMPLE
^^^^^^^

.. code-block:: cmake

  # ...
  set(CMAKE_AUTORCC_OPTIONS "--compress;9")
  # ...


code:
CMAKE_AUTOUIC
-------------

Whether to handle ``uic`` automatically for Qt targets.

This variable is used to initialize the :prop_tgt:`AUTOUIC` property on all
the targets.  See that target property for additional information.


code:
CMAKE_AUTOUIC_EXECUTABLE
------------------------

.. versionadded:: 3.27

This variable is used to initialize the :prop_tgt:`AUTOUIC_EXECUTABLE`
property on all the targets. See that target property for additional
information.

By default it is empty.


code:
CMAKE_AUTOUIC_OPTIONS
---------------------

Additional options for ``uic`` when using :variable:`CMAKE_AUTOUIC`.

This variable is used to initialize the :prop_tgt:`AUTOUIC_OPTIONS` property on
all the targets.  See that target property for additional information.

EXAMPLE
^^^^^^^

.. code-block:: cmake

  # ...
  set_property(CMAKE_AUTOUIC_OPTIONS "--no-protection")
  # ...


code:
CMAKE_AUTOUIC_SEARCH_PATHS
--------------------------

.. versionadded:: 3.9

Search path list used by :variable:`CMAKE_AUTOUIC` to find included
``.ui`` files.

This variable is used to initialize the :prop_tgt:`AUTOUIC_SEARCH_PATHS`
property on all the targets. See that target property for additional
information.

By default it is empty.


code:
CMAKE_BACKWARDS_COMPATIBILITY
-----------------------------

Deprecated.  See CMake Policy :policy:`CMP0001` documentation.


code:
CMAKE_BINARY_DIR
----------------

The path to the top level of the build tree.

This is the full path to the top level of the current CMake build
tree.  For an in-source build, this would be the same as
:variable:`CMAKE_SOURCE_DIR`.

When run in :option:`cmake -P` script mode, CMake sets the variables
``CMAKE_BINARY_DIR``, :variable:`CMAKE_SOURCE_DIR`,
:variable:`CMAKE_CURRENT_BINARY_DIR` and
:variable:`CMAKE_CURRENT_SOURCE_DIR` to the current working directory.


code:
CMAKE_BUILD_RPATH
-----------------

.. versionadded:: 3.8

:ref:`Semicolon-separated list <CMake Language Lists>` specifying runtime path (``RPATH``)
entries to add to binaries linked in the build tree (for platforms that
support it).  The entries will *not* be used for binaries in the install
tree.  See also the :variable:`CMAKE_INSTALL_RPATH` variable.

This is used to initialize the :prop_tgt:`BUILD_RPATH` target property
for all targets.


code:
CMAKE_BUILD_RPATH_USE_ORIGIN
----------------------------

.. versionadded:: 3.14

Whether to use relative paths for the build ``RPATH``.

This is used to initialize the :prop_tgt:`BUILD_RPATH_USE_ORIGIN` target
property for all targets, see that property for more details.


code:
CMAKE_BUILD_TOOL
----------------

This variable exists only for backwards compatibility.
It contains the same value as :variable:`CMAKE_MAKE_PROGRAM`.
Use that variable instead.


code:
CMAKE_BUILD_TYPE
----------------

Specifies the build type on single-configuration generators (e.g.
:ref:`Makefile Generators` or :generator:`Ninja`).  Typical values include
``Debug``, ``Release``, ``RelWithDebInfo`` and ``MinSizeRel``, but custom
build types can also be defined.

This variable is initialized by the first :command:`project` or
:command:`enable_language` command called in a project when a new build
tree is first created.  If the :envvar:`CMAKE_BUILD_TYPE` environment
variable is set, its value is used.  Otherwise, a toolchain-specific
default is chosen when a language is enabled.  The default value is often
an empty string, but this is usually not desirable and one of the other
standard build types is usually more appropriate.

Depending on the situation, the value of this variable may be treated
case-sensitively or case-insensitively.  See :ref:`Build Configurations`
for discussion of this and other related topics.

For multi-config generators, see :variable:`CMAKE_CONFIGURATION_TYPES`.


code:
CMAKE_BUILD_WITH_INSTALL_NAME_DIR
---------------------------------

.. versionadded:: 3.9

Whether to use :prop_tgt:`INSTALL_NAME_DIR` on targets in the build tree.

This variable is used to initialize the :prop_tgt:`BUILD_WITH_INSTALL_NAME_DIR`
property on all targets.


code:
CMAKE_BUILD_WITH_INSTALL_RPATH
------------------------------

Use the install path for the ``RPATH``.

Normally CMake uses the build tree for the ``RPATH`` when building
executables etc on systems that use ``RPATH``.  When the software is
installed the executables etc are relinked by CMake to have the
install ``RPATH``.  If this variable is set to true then the software is
always built with the install path for the ``RPATH`` and does not need to
be relinked when installed.

This is used to initialize the :prop_tgt:`BUILD_WITH_INSTALL_RPATH` target property
for all targets.


code:
CMAKE_CACHEFILE_DIR
-------------------

This variable is used internally by CMake, and may not be set during
the first configuration of a build tree.  When it is set, it has the
same value as :variable:`CMAKE_BINARY_DIR`.  Use that variable instead.


code:
CMAKE_CACHE_MAJOR_VERSION
-------------------------

Major version of CMake used to create the ``CMakeCache.txt`` file

This stores the major version of CMake used to write a CMake cache
file.  It is only different when a different version of CMake is run
on a previously created cache file.


code:
CMAKE_CACHE_MINOR_VERSION
-------------------------

Minor version of CMake used to create the ``CMakeCache.txt`` file

This stores the minor version of CMake used to write a CMake cache
file.  It is only different when a different version of CMake is run
on a previously created cache file.


code:
CMAKE_CACHE_PATCH_VERSION
-------------------------

Patch version of CMake used to create the ``CMakeCache.txt`` file

This stores the patch version of CMake used to write a CMake cache
file.  It is only different when a different version of CMake is run
on a previously created cache file.


code:
CMAKE_CFG_INTDIR
----------------

.. deprecated:: 3.21

  This variable has poor support on :generator:`Ninja Multi-Config`, and
  predates the existence of the :genex:`$<CONFIG>` generator expression. Use
  ``$<CONFIG>`` instead.

Build-time reference to per-configuration output subdirectory.

For native build systems supporting multiple configurations in the
build tree (such as :ref:`Visual Studio Generators` and :generator:`Xcode`),
the value is a reference to a build-time variable specifying the name
of the per-configuration output subdirectory.  On :ref:`Makefile Generators`
this evaluates to `.` because there is only one configuration in a build tree.
Example values:

::

  $(ConfigurationName) = Visual Studio 9
  $(Configuration)     = Visual Studio 12 and above
  $(CONFIGURATION)     = Xcode
  .                    = Make-based tools
  .                    = Ninja
  ${CONFIGURATION}     = Ninja Multi-Config

Since these values are evaluated by the native build system, this
variable is suitable only for use in command lines that will be
evaluated at build time.  Example of intended usage:

::

  add_executable(mytool mytool.c)
  add_custom_command(
    OUTPUT out.txt
    COMMAND ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/mytool
            ${CMAKE_CURRENT_SOURCE_DIR}/in.txt out.txt
    DEPENDS mytool in.txt
    )
  add_custom_target(drive ALL DEPENDS out.txt)

Note that ``CMAKE_CFG_INTDIR`` is no longer necessary for this purpose but
has been left for compatibility with existing projects.  Instead
:command:`add_custom_command` recognizes executable target names in its
``COMMAND`` option, so
``${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/mytool`` can be replaced
by just ``mytool``.

This variable is read-only.  Setting it is undefined behavior.  In
multi-configuration build systems the value of this variable is passed
as the value of preprocessor symbol ``CMAKE_INTDIR`` to the compilation
of all source files.


code:
CMAKE_CLANG_VFS_OVERLAY
-----------------------

.. versionadded:: 3.19

When cross compiling for windows with clang-cl, this variable can be an
absolute path pointing to a clang virtual file system yaml file, which
will enable clang-cl to resolve windows header names on a case sensitive
file system.


code:
CMAKE_CL_64
-----------

Discouraged.  Use :variable:`CMAKE_SIZEOF_VOID_P` instead.

Set to a true value when using a Microsoft Visual Studio ``cl`` compiler that
*targets* a 64-bit architecture.


code:
CMAKE_CODEBLOCKS_COMPILER_ID
----------------------------

.. versionadded:: 3.11

Change the compiler id in the generated CodeBlocks project files.

CodeBlocks uses its own compiler id string which differs from
:variable:`CMAKE_<LANG>_COMPILER_ID`.  If this variable is left empty,
CMake tries to recognize the CodeBlocks compiler id automatically.
Otherwise the specified string is used in the CodeBlocks project file.
See the CodeBlocks documentation for valid compiler id strings.

Other IDEs like QtCreator that also use the CodeBlocks generator may ignore
this setting.


code:
CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES
---------------------------------------

.. versionadded:: 3.10

Change the way the CodeBlocks generator creates project files.

If this variable evaluates to ``ON`` the generator excludes from
the project file any files that are located outside the project root.


code:
CMAKE_CODELITE_USE_TARGETS
--------------------------

.. versionadded:: 3.7

Change the way the CodeLite generator creates projectfiles.

If this variable evaluates to ``ON`` at the end of the top-level
``CMakeLists.txt`` file, the generator creates projectfiles based on targets
rather than projects.


code:
CMAKE_COLOR_DIAGNOSTICS
-----------------------

.. versionadded:: 3.24

Enable color diagnostics throughout.

This variable uses three states: ``ON``, ``OFF`` and not defined.

When not defined:

* :ref:`Makefile Generators` initialize the :variable:`CMAKE_COLOR_MAKEFILE`
  variable to ``ON``.  It controls color buildsystem messages.

* GNU/Clang compilers are not invoked with any color diagnostics flag.

When ``ON``:

* :ref:`Makefile Generators` produce color buildsystem messages by default.
  :variable:`CMAKE_COLOR_MAKEFILE` is not initialized, but may be
  explicitly set to ``OFF`` to disable color buildsystem messages.

* GNU/Clang compilers are invoked with a flag enabling color diagnostics
  (``-fcolor-diagnostics``).

When ``OFF``:

* :ref:`Makefile Generators` do not produce color buildsystem messages by
  default.  :variable:`CMAKE_COLOR_MAKEFILE` is not initialized, but may be
  explicitly set to ``ON`` to enable color buildsystem messages.

* GNU/Clang compilers are invoked with a flag disabling color diagnostics
  (``-fno-color-diagnostics``).

If the :envvar:`CMAKE_COLOR_DIAGNOSTICS` environment variable is set, its
value is used.  Otherwise, ``CMAKE_COLOR_DIAGNOSTICS`` is not defined by
default.


code:
CMAKE_COLOR_MAKEFILE
--------------------

Enables color output when using the :ref:`Makefile Generators`.

When enabled, the generated Makefiles will produce colored output.
Default is ``ON``.


code:
CMAKE_COMMAND
-------------

The full path to the :manual:`cmake(1)` executable.

This is the full path to the CMake executable :manual:`cmake(1)` which is
useful from custom commands that want to use the :option:`cmake -E` option for
portable system commands.  (e.g.  ``/usr/local/bin/cmake``)


code:
CMAKE_COMPILER_2005
-------------------

Using the Visual Studio 2005 compiler from Microsoft

Set to true when using the Visual Studio 2005 compiler from Microsoft.


code:
CMAKE_COMPILER_IS_GNUCC
-----------------------

True if the ``C`` compiler is GNU.

This variable is deprecated.  Use
:variable:`CMAKE_C_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` instead.


code:
CMAKE_COMPILER_IS_GNUCXX
------------------------

True if the C++ (``CXX``) compiler is GNU.

This variable is deprecated.  Use
:variable:`CMAKE_CXX_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` instead.


code:
CMAKE_COMPILER_IS_GNUG77
------------------------

True if the ``Fortran`` compiler is GNU.

This variable is deprecated.  Use
:variable:`CMAKE_Fortran_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` instead.


code:
CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY
----------------------------------

.. versionadded:: 3.1

Output directory for MS debug symbol ``.pdb`` files
generated by the compiler while building source files.

This variable is used to initialize the
:prop_tgt:`COMPILE_PDB_OUTPUT_DIRECTORY` property on all the targets.


code:
CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>
-------------------------------------------

.. versionadded:: 3.1

Per-configuration output directory for MS debug symbol ``.pdb`` files
generated by the compiler while building source files.

This is a per-configuration version of
:variable:`CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY`.
This variable is used to initialize the
:prop_tgt:`COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>`
property on all the targets.


code:
CMAKE_COMPILE_WARNING_AS_ERROR
------------------------------

.. versionadded:: 3.24

Specify whether to treat warnings on compile as errors.

This variable is used to initialize the
:prop_tgt:`COMPILE_WARNING_AS_ERROR` property on all the targets.


code:
CMAKE_CONFIGURATION_TYPES
-------------------------

Specifies the available build types (configurations) on multi-config
generators (e.g. :ref:`Visual Studio <Visual Studio Generators>`,
:generator:`Xcode`, or :generator:`Ninja Multi-Config`) as a
:ref:`semicolon-separated list <CMake Language Lists>`.  Typical entries
include ``Debug``, ``Release``, ``RelWithDebInfo`` and ``MinSizeRel``,
but custom build types can also be defined.

This variable is initialized by the first :command:`project` or
:command:`enable_language` command called in a project when a new build
tree is first created.  If the :envvar:`CMAKE_CONFIGURATION_TYPES`
environment variable is set, its value is used.  Otherwise, the default
value is generator-specific.

Depending on the situation, the values in this variable may be treated
case-sensitively or case-insensitively.  See :ref:`Build Configurations`
for discussion of this and other related topics.

For single-config generators, see :variable:`CMAKE_BUILD_TYPE`.


code:
CMAKE_<CONFIG>_POSTFIX
----------------------

Default filename postfix for libraries under configuration ``<CONFIG>``.

When a non-executable target is created its :prop_tgt:`<CONFIG>_POSTFIX`
target property is initialized with the value of this variable if it is set.


code:
CMAKE_CPACK_COMMAND
-------------------

.. versionadded:: 3.13

Full path to :manual:`cpack(1)` command installed with CMake.

This is the full path to the CPack executable :manual:`cpack(1)`
that can be used for custom commands or tests to invoke
CPack commands.


code:
CMAKE_CROSSCOMPILING
--------------------

This variable is set by CMake to indicate whether it is cross compiling,
but note limitations discussed below.

This variable will be set to true by CMake if the :variable:`CMAKE_SYSTEM_NAME`
variable has been set manually (i.e. in a toolchain file or as a cache entry
from the :manual:`cmake <cmake(1)>` command line). In most cases, manually
setting :variable:`CMAKE_SYSTEM_NAME` will only be done when cross compiling
since, if not manually set, it will be given the same value as
:variable:`CMAKE_HOST_SYSTEM_NAME`, which is correct for
the non-cross-compiling case. In the event that :variable:`CMAKE_SYSTEM_NAME`
is manually set to the same value as :variable:`CMAKE_HOST_SYSTEM_NAME`, then
``CMAKE_CROSSCOMPILING`` will still be set to true.

Another case to be aware of is that builds targeting Apple platforms other than
macOS are handled differently to other cross compiling scenarios. Rather than
relying on :variable:`CMAKE_SYSTEM_NAME` to select the target platform, Apple
device builds use :variable:`CMAKE_OSX_SYSROOT` to select the appropriate SDK,
which indirectly determines the target platform. Furthermore, when using the
:generator:`Xcode` generator, developers can switch between device and
simulator builds at build time rather than having a single
choice at configure time, so the concept
of whether the build is cross compiling or not is more complex. Therefore, the
use of ``CMAKE_CROSSCOMPILING`` is not recommended for projects targeting Apple
devices.


code:
CMAKE_CROSSCOMPILING_EMULATOR
-----------------------------

.. versionadded:: 3.3

This variable is only used when :variable:`CMAKE_CROSSCOMPILING` is on. It
should point to a command on the host system that can run executable built
for the target system.

.. versionadded:: 3.15
  If this variable contains a :ref:`semicolon-separated list <CMake Language
  Lists>`, then the first value is the command and remaining values are its
  arguments.

.. versionadded:: 3.28
  This variable can be initialized via an
  :envvar:`CMAKE_CROSSCOMPILING_EMULATOR` environment variable.

The command will be used to run :command:`try_run` generated executables,
which avoids manual population of the ``TryRunResults.cmake`` file.

This variable is also used as the default value for the
:prop_tgt:`CROSSCOMPILING_EMULATOR` target property of executables.  However,
while :manual:`generator expressions <cmake-generator-expressions(7)>` are
supported by the target property (since CMake 3.29), they are *not* supported
by this variable's :command:`try_run` functionality.


code:
CMAKE_CROSS_CONFIGS
-------------------

.. versionadded:: 3.17

Specifies a :ref:`semicolon-separated list <CMake Language Lists>` of
configurations available from all ``build-<Config>.ninja`` files in the
:generator:`Ninja Multi-Config` generator.  This variable activates
cross-config mode. Targets from each config specified in this variable can be
built from any ``build-<Config>.ninja`` file. Custom commands will use the
configuration native to ``build-<Config>.ninja``. If it is set to ``all``, all
configurations from :variable:`CMAKE_CONFIGURATION_TYPES` are cross-configs. If
it is not specified, or empty, each ``build-<Config>.ninja`` file will only
contain build rules for its own configuration.

The value of this variable must be a subset of
:variable:`CMAKE_CONFIGURATION_TYPES`.


code:
CMAKE_CTEST_ARGUMENTS
---------------------

.. versionadded:: 3.17

Set this to a :ref:`semicolon-separated list <CMake Language Lists>` of
command-line arguments to pass to :manual:`ctest(1)` when running tests
through the ``test`` (or ``RUN_TESTS``) target of the generated build system.


code:
CMAKE_CTEST_COMMAND
-------------------

Full path to :manual:`ctest(1)` command installed with CMake.

This is the full path to the CTest executable :manual:`ctest(1)`
that can be used for custom commands or tests to invoke
CTest commands.


code:
CMAKE_CUDA_ARCHITECTURES
------------------------

.. versionadded:: 3.18

Default value for :prop_tgt:`CUDA_ARCHITECTURES` property of targets.

Initialized by the :envvar:`CUDAARCHS` environment variable if set.
Otherwise as follows depending on :variable:`CMAKE_CUDA_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>`:

- For ``Clang``: the oldest architecture that works.

- For ``NVIDIA``: the default architecture chosen by the compiler.
  See policy :policy:`CMP0104`.

Users are encouraged to override this, as the default varies across compilers
and compiler versions.

This variable is used to initialize the :prop_tgt:`CUDA_ARCHITECTURES` property
on all targets. See the target property for additional information.

Examples
^^^^^^^^

.. code-block:: cmake

  cmake_minimum_required(VERSION)

  if(NOT DEFINED CMAKE_CUDA_ARCHITECTURES)
    set(CMAKE_CUDA_ARCHITECTURES 75)
  endif()

  project(example LANGUAGES CUDA)

``CMAKE_CUDA_ARCHITECTURES`` will default to ``75`` unless overridden by the user.


code:
CMAKE_CUDA_COMPILE_FEATURES
---------------------------

.. versionadded:: 3.17

List of features known to the CUDA compiler

These features are known to be available for use with the CUDA compiler. This
list is a subset of the features listed in the
:prop_gbl:`CMAKE_CUDA_KNOWN_FEATURES` global property.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CUDA_EXTENSIONS
---------------------

.. versionadded:: 3.8

Default value for :prop_tgt:`CUDA_EXTENSIONS` target property if set when a
target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CUDA_HOST_COMPILER
------------------------

.. versionadded:: 3.10

This is the original CUDA-specific name for the more general
:variable:`CMAKE_<LANG>_HOST_COMPILER` variable.  See the latter
for details.


code:
CMAKE_CUDA_RESOLVE_DEVICE_SYMBOLS
---------------------------------

.. versionadded:: 3.16

Default value for :prop_tgt:`CUDA_RESOLVE_DEVICE_SYMBOLS` target
property when defined. By default this variable is not defined.

This variable is used to initialize the property on each target as
it is created.


code:
CMAKE_CUDA_RUNTIME_LIBRARY
--------------------------

.. versionadded:: 3.17

Select the CUDA runtime library for use when compiling and linking CUDA.
This variable is used to initialize the :prop_tgt:`CUDA_RUNTIME_LIBRARY`
property on all targets as they are created.

The allowed case insensitive values are:

.. include:: ../prop_tgt/CUDA_RUNTIME_LIBRARY-VALUES.txt

Contents of ``CMAKE_CUDA_RUNTIME_LIBRARY`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.

If this variable is not set then the :prop_tgt:`CUDA_RUNTIME_LIBRARY` target
property will not be set automatically.  If that property is not set then
CMake uses an appropriate default value based on the compiler to select the
CUDA runtime library.

.. note::

  This property has effect only when the ``CUDA`` language is enabled. To
  control the CUDA runtime linking when only using the CUDA SDK with the
  ``C`` or ``C++`` language we recommend using the :module:`FindCUDAToolkit`
  module.


code:
CMAKE_CUDA_SEPARABLE_COMPILATION
--------------------------------

.. versionadded:: 3.11

Default value for :prop_tgt:`CUDA_SEPARABLE_COMPILATION` target property.
This variable is used to initialize the property on each target as it is
created.


code:
CMAKE_CUDA_STANDARD
-------------------

.. versionadded:: 3.8

Default value for :prop_tgt:`CUDA_STANDARD` target property if set when a
target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CUDA_STANDARD_REQUIRED
----------------------------

.. versionadded:: 3.8

Default value for :prop_tgt:`CUDA_STANDARD_REQUIRED` target property if set
when a target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES
--------------------------------------

.. versionadded:: 3.8

When the ``CUDA`` language has been enabled, this provides a
:ref:`semicolon-separated list <CMake Language Lists>` of include directories provided
by the CUDA Toolkit.  The value may be useful for C++ source files
to include CUDA headers.


code:
CMAKE_CURRENT_BINARY_DIR
------------------------

The path to the binary directory currently being processed.

This is the full path to the build directory that is currently being
processed by cmake.  Each directory added by :command:`add_subdirectory` will
create a binary directory in the build tree, and as it is being
processed this variable will be set.  For in-source builds this is the
current source directory being processed.

When run in :option:`cmake -P` script mode, CMake sets the variables
:variable:`CMAKE_BINARY_DIR`, :variable:`CMAKE_SOURCE_DIR`,
``CMAKE_CURRENT_BINARY_DIR`` and
:variable:`CMAKE_CURRENT_SOURCE_DIR` to the current working directory.


code:
CMAKE_CURRENT_FUNCTION
----------------------

.. versionadded:: 3.17

When executing code inside a :command:`function`, this variable
contains the name of the current function.  It can be useful for
diagnostic or debug messages.

See also :variable:`CMAKE_CURRENT_FUNCTION_LIST_DIR`,
:variable:`CMAKE_CURRENT_FUNCTION_LIST_FILE` and
:variable:`CMAKE_CURRENT_FUNCTION_LIST_LINE`.


code:
CMAKE_CURRENT_FUNCTION_LIST_DIR
-------------------------------

.. versionadded:: 3.17

When executing code inside a :command:`function`, this variable
contains the full directory of the listfile that defined the current function.

It is quite common practice in CMake for modules to use some additional files,
such as templates to be copied in after substituting CMake variables.
In such cases, a function needs to know where to locate those files in a way
that doesn't depend on where the function is called.  Without
``CMAKE_CURRENT_FUNCTION_LIST_DIR``, the code to do that would typically use
the following pattern:

.. code-block:: cmake

  set(_THIS_MODULE_BASE_DIR "${CMAKE_CURRENT_LIST_DIR}")

  function(foo)
    configure_file(
      "${_THIS_MODULE_BASE_DIR}/some.template.in"
      some.output
    )
  endfunction()

Using ``CMAKE_CURRENT_FUNCTION_LIST_DIR`` inside the function instead
eliminates the need for the extra variable which would otherwise be visible
outside the function's scope.
The above example can be written in the more concise and more robust form:

.. code-block:: cmake

  function(foo)
    configure_file(
      "${CMAKE_CURRENT_FUNCTION_LIST_DIR}/some.template.in"
      some.output
    )
  endfunction()

See also :variable:`CMAKE_CURRENT_FUNCTION`,
:variable:`CMAKE_CURRENT_FUNCTION_LIST_FILE` and
:variable:`CMAKE_CURRENT_FUNCTION_LIST_LINE`.


code:
CMAKE_CURRENT_FUNCTION_LIST_FILE
--------------------------------

.. versionadded:: 3.17

When executing code inside a :command:`function`, this variable
contains the full path to the listfile that defined the current function.

See also :variable:`CMAKE_CURRENT_FUNCTION`,
:variable:`CMAKE_CURRENT_FUNCTION_LIST_DIR` and
:variable:`CMAKE_CURRENT_FUNCTION_LIST_LINE`.


code:
CMAKE_CURRENT_FUNCTION_LIST_LINE
--------------------------------

.. versionadded:: 3.17

When executing code inside a :command:`function`, this variable
contains the line number in the listfile where the current function
was defined.

See also :variable:`CMAKE_CURRENT_FUNCTION`,
:variable:`CMAKE_CURRENT_FUNCTION_LIST_DIR` and
:variable:`CMAKE_CURRENT_FUNCTION_LIST_FILE`.


code:
CMAKE_CURRENT_LIST_DIR
----------------------

Full directory of the listfile currently being processed.

As CMake processes the listfiles in your project this variable will
always be set to the directory where the listfile which is currently
being processed (:variable:`CMAKE_CURRENT_LIST_FILE`) is located.  The value
has dynamic scope.  When CMake starts processing commands in a source file
it sets this variable to the directory where this file is located.
When CMake finishes processing commands from the file it restores the
previous value.  Therefore the value of the variable inside a macro or
function is the directory of the file invoking the bottom-most entry
on the call stack, not the directory of the file containing the macro
or function definition.

See also :variable:`CMAKE_CURRENT_LIST_FILE`.


code:
CMAKE_CURRENT_LIST_FILE
-----------------------

Full path to the listfile currently being processed.

As CMake processes the listfiles in your project this variable will
always be set to the one currently being processed.  The value has
dynamic scope.  When CMake starts processing commands in a source file
it sets this variable to the location of the file.  When CMake
finishes processing commands from the file it restores the previous
value.  Therefore the value of the variable inside a macro or function
is the file invoking the bottom-most entry on the call stack, not the
file containing the macro or function definition.

See also :variable:`CMAKE_PARENT_LIST_FILE`.


code:
CMAKE_CURRENT_LIST_LINE
-----------------------

The line number of the current file being processed.

This is the line number of the file currently being processed by
cmake.

If CMake is currently processing deferred calls scheduled by
the :command:`cmake_language(DEFER)` command, this variable
evaluates to ``DEFERRED`` instead of a specific line number.


code:
CMAKE_CURRENT_SOURCE_DIR
------------------------

The path to the source directory currently being processed.

This is the full path to the source directory that is currently being
processed by cmake.

When run in :option:`cmake -P` script mode, CMake sets the variables
:variable:`CMAKE_BINARY_DIR`, :variable:`CMAKE_SOURCE_DIR`,
:variable:`CMAKE_CURRENT_BINARY_DIR` and
``CMAKE_CURRENT_SOURCE_DIR`` to the current working directory.


code:
CMAKE_CXX_COMPILE_FEATURES
--------------------------

.. versionadded:: 3.1

List of features known to the C++ compiler

These features are known to be available for use with the C++ compiler. This
list is a subset of the features listed in the
:prop_gbl:`CMAKE_CXX_KNOWN_FEATURES` global property.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CXX_EXTENSIONS
--------------------

.. versionadded:: 3.1

Default value for :prop_tgt:`CXX_EXTENSIONS` target property if set when a
target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CXX_SCAN_FOR_MODULES
--------------------------

.. versionadded:: 3.28

Whether to scan C++ source files for module dependencies.

This variable is used to initialize the :prop_tgt:`CXX_SCAN_FOR_MODULES`
property on all the targets.  See that target property for additional
information.


code:
CMAKE_CXX_STANDARD
------------------

.. versionadded:: 3.1

Default value for :prop_tgt:`CXX_STANDARD` target property if set when a target
is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CXX_STANDARD_REQUIRED
---------------------------

.. versionadded:: 3.1

Default value for :prop_tgt:`CXX_STANDARD_REQUIRED` target property if set when
a target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_C_COMPILE_FEATURES
------------------------

.. versionadded:: 3.1

List of features known to the C compiler

These features are known to be available for use with the C compiler. This
list is a subset of the features listed in the
:prop_gbl:`CMAKE_C_KNOWN_FEATURES` global property.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_C_EXTENSIONS
------------------

.. versionadded:: 3.1

Default value for :prop_tgt:`C_EXTENSIONS` target property if set when a target
is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_C_STANDARD
----------------

.. versionadded:: 3.1

Default value for :prop_tgt:`C_STANDARD` target property if set when a target
is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_C_STANDARD_REQUIRED
-------------------------

.. versionadded:: 3.1

Default value for :prop_tgt:`C_STANDARD_REQUIRED` target property if set when
a target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_DEBUG_POSTFIX
-------------------

See variable :variable:`CMAKE_<CONFIG>_POSTFIX`.

This variable is a special case of the more-general
:variable:`CMAKE_<CONFIG>_POSTFIX` variable for the `DEBUG` configuration.


code:
CMAKE_DEBUG_TARGET_PROPERTIES
-----------------------------

Enables tracing output for target properties.

This variable can be populated with a list of properties to generate
debug output for when evaluating target properties.  Currently it can
only be used when evaluating:

* :prop_tgt:`AUTOUIC_OPTIONS`
* :prop_tgt:`COMPILE_DEFINITIONS`
* :prop_tgt:`COMPILE_FEATURES`
* :prop_tgt:`COMPILE_OPTIONS`
* :prop_tgt:`INCLUDE_DIRECTORIES`
* :prop_tgt:`LINK_DIRECTORIES`
* :prop_tgt:`LINK_OPTIONS`
* :prop_tgt:`POSITION_INDEPENDENT_CODE`
* :prop_tgt:`SOURCES`

target properties and any other property listed in
:prop_tgt:`COMPATIBLE_INTERFACE_STRING` and other
``COMPATIBLE_INTERFACE_`` properties.  It outputs an origin for each entry
in the target property.  Default is unset.


code:
CMAKE_DEFAULT_BUILD_TYPE
------------------------

.. versionadded:: 3.17

Specifies the configuration to use by default in a ``build.ninja`` file in the
:generator:`Ninja Multi-Config` generator. If this variable is specified,
``build.ninja`` uses build rules from ``build-<Config>.ninja`` by default. All
custom commands are executed with this configuration. If the variable is not
specified, the first item from :variable:`CMAKE_CONFIGURATION_TYPES` is used
instead.

The value of this variable must be one of the items from
:variable:`CMAKE_CONFIGURATION_TYPES`.


code:
CMAKE_DEFAULT_CONFIGS
---------------------

.. versionadded:: 3.17

Specifies a :ref:`semicolon-separated list <CMake Language Lists>` of configurations
to build for a target in ``build.ninja`` if no ``:<Config>`` suffix is specified in
the :generator:`Ninja Multi-Config` generator. If it is set to ``all``, all
configurations from :variable:`CMAKE_CROSS_CONFIGS` are used. If it is not
specified, it defaults to :variable:`CMAKE_DEFAULT_BUILD_TYPE`.

For example, if you set :variable:`CMAKE_DEFAULT_BUILD_TYPE` to ``Release``,
but set ``CMAKE_DEFAULT_CONFIGS`` to ``Debug`` or ``all``, all
``<target>`` aliases in ``build.ninja`` will resolve to ``<target>:Debug`` or
``<target>:all``, but custom commands will still use the ``Release``
configuration.

The value of this variable must be a subset of :variable:`CMAKE_CROSS_CONFIGS`
or be the same as :variable:`CMAKE_DEFAULT_BUILD_TYPE`. It must not be
specified if :variable:`CMAKE_DEFAULT_BUILD_TYPE` or
:variable:`CMAKE_CROSS_CONFIGS` is not used.


code:
CMAKE_DEPENDS_IN_PROJECT_ONLY
-----------------------------

.. versionadded:: 3.6

When set to ``TRUE`` in a directory, the build system produced by the
:ref:`Makefile Generators` is set up to only consider dependencies on source
files that appear either in the source or in the binary directories.  Changes
to source files outside of these directories will not cause rebuilds.

This should be used carefully in cases where some source files are picked up
through external headers during the build.


code:
CMAKE_DEPENDS_USE_COMPILER
--------------------------

.. versionadded:: 3.20

For the :ref:`Makefile Generators`, source dependencies are now, for a
selection of compilers, generated by the compiler itself. By defining this
variable with value ``FALSE``, you can restore the legacy behavior (i.e. using
CMake for dependencies discovery).


code:
CMAKE_DIRECTORY_LABELS
-----------------------

.. versionadded:: 3.10

Specify labels for the current directory.

This is used to initialize the :prop_dir:`LABELS` directory property.


code:
CMAKE_DISABLE_FIND_PACKAGE_<PackageName>
----------------------------------------

Variable for disabling :command:`find_package` calls.

Every non-``REQUIRED`` :command:`find_package` call in a project can be
disabled by setting the variable
``CMAKE_DISABLE_FIND_PACKAGE_<PackageName>`` to ``TRUE``.
This can be used to build a project without an optional package,
although that package is installed.

This switch should be used during the initial CMake run.  Otherwise if
the package has already been found in a previous CMake run, the
variables which have been stored in the cache will still be there.  In
that case it is recommended to remove the cache variables for this
package from the cache using the cache editor or :option:`cmake -U`.

Note that this variable can lead to inconsistent results within the project.
Consider the case where a dependency is requested via :command:`find_package`
from two different places within the project.  If the first call does not
have the ``REQUIRED`` keyword, it will not find the dependency when
``CMAKE_DISABLE_FIND_PACKAGE_<PackageName>`` is set to true for that
dependency.  The project will proceed under the assumption that the dependency
isn't available.  If the second call elsewhere in the project *does* have the
``REQUIRED`` keyword, it can succeed.  Two different parts of the same project
have then seen opposite results for the same dependency.

See also the :variable:`CMAKE_REQUIRE_FIND_PACKAGE_<PackageName>` variable.


code:
CMAKE_DISABLE_PRECOMPILE_HEADERS
--------------------------------

.. versionadded:: 3.16

Default value for :prop_tgt:`DISABLE_PRECOMPILE_HEADERS` of targets.

By default ``CMAKE_DISABLE_PRECOMPILE_HEADERS`` is ``OFF``.


code:
CMAKE_DLL_NAME_WITH_SOVERSION
-----------------------------

.. versionadded:: 3.27

This variable is used to initialize the :prop_tgt:`DLL_NAME_WITH_SOVERSION`
property on shared library targets for the Windows platform, which is selected
when the :variable:`WIN32` variable is set.

See this target property for additional information.

Please note that setting this variable has no effect if versioned filenames
are globally disabled with the :variable:`CMAKE_PLATFORM_NO_VERSIONED_SONAME`
variable.


code:
CMAKE_DL_LIBS
-------------

Name of library containing ``dlopen`` and ``dlclose``.

The name of the library that has ``dlopen`` and ``dlclose`` in it, usually
``-ldl`` on most UNIX machines.


code:
CMAKE_DOTNET_SDK
----------------

.. versionadded:: 3.23

Default value for :prop_tgt:`DOTNET_SDK` property of targets.

This variable is used to initialize the :prop_tgt:`DOTNET_SDK`
property on all targets. See that target property for additional information.


code:
CMAKE_DOTNET_TARGET_FRAMEWORK
-----------------------------

.. versionadded:: 3.17

Default value for :prop_tgt:`DOTNET_TARGET_FRAMEWORK` property	of
targets.

This variable is used to initialize the
:prop_tgt:`DOTNET_TARGET_FRAMEWORK` property on all targets. See that
target property for additional information.

Setting ``CMAKE_DOTNET_TARGET_FRAMEWORK`` may be necessary
when working with ``C#`` and newer .NET framework versions to
avoid referencing errors with the ``ALL_BUILD`` CMake target.

This variable is only evaluated for :ref:`Visual Studio Generators`
VS 2010 and above.


code:
CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION
-------------------------------------

.. versionadded:: 3.12

Default value for :prop_tgt:`DOTNET_TARGET_FRAMEWORK_VERSION`
property of targets.

This variable is used to initialize the
:prop_tgt:`DOTNET_TARGET_FRAMEWORK_VERSION` property on all
targets. See that target property for additional information. When set,
:variable:`CMAKE_DOTNET_TARGET_FRAMEWORK` takes precednece over this
variable. See that variable or the associated target property
:prop_tgt:`DOTNET_TARGET_FRAMEWORK` for additional information.

Setting ``CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION`` may be necessary
when working with ``C#`` and newer .NET framework versions to
avoid referencing errors with the ``ALL_BUILD`` CMake target.

This variable is only evaluated for :ref:`Visual Studio Generators`
VS 2010 and above.


code:
CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES
---------------------------------------

.. versionadded:: 3.6

This cache variable is used by the Eclipse project generator.  See
:manual:`cmake-generators(7)`.

The Eclipse project generator generates so-called linked resources
e.g. to the subproject root dirs in the source tree or to the source files
of targets.
This can be disabled by setting this variable to FALSE.


code:
CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT
-------------------------------------

.. versionadded:: 3.6

This cache variable is used by the Eclipse project generator.  See
:manual:`cmake-generators(7)`.

If this variable is set to TRUE, the Eclipse project generator will generate
an Eclipse project in :variable:`CMAKE_SOURCE_DIR` . This project can then
be used in Eclipse e.g. for the version control functionality.
``CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT`` defaults to ``FALSE``; so
nothing is written into the source directory.


code:
CMAKE_ECLIPSE_MAKE_ARGUMENTS
----------------------------

.. versionadded:: 3.6

This cache variable is used by the Eclipse project generator.  See
:manual:`cmake-generators(7)`.

This variable holds arguments which are used when Eclipse invokes the make
tool. By default it is initialized to hold flags to enable parallel builds
(using -j typically).


code:
CMAKE_ECLIPSE_RESOURCE_ENCODING
-------------------------------

.. versionadded:: 3.16

This cache variable tells the :generator:`Eclipse CDT4` project generator
to set the resource encoding to the given value in generated project files.
If no value is given, no encoding will be set.


code:
CMAKE_ECLIPSE_VERSION
---------------------

.. versionadded:: 3.6

This cache variable is used by the Eclipse project generator.  See
:manual:`cmake-generators(7)`.

When using the Eclipse project generator, CMake tries to find the Eclipse
executable and detect the version of it. Depending on the version it finds,
some features are enabled or disabled. If CMake doesn't find
Eclipse, it assumes the oldest supported version, Eclipse Callisto (3.2).


code:
CMAKE_EDIT_COMMAND
------------------

Full path to :manual:`cmake-gui(1)` or :manual:`ccmake(1)`.  Defined only for
:ref:`Makefile Generators` and :ref:`Ninja Generators` when not using any
:ref:`Extra Generators`.

This is the full path to the CMake executable that can graphically
edit the cache.  For example, :manual:`cmake-gui(1)` or :manual:`ccmake(1)`.


code:
CMAKE_ENABLE_EXPORTS
--------------------

.. versionadded:: 3.4

Specify whether executables export symbols for loadable modules.

This variable is used to initialize the :prop_tgt:`ENABLE_EXPORTS` target
property for executable targets when they are created by calls to the
:command:`add_executable` command.  See the property documentation for details.

This variable has been superseded by the
:variable:`CMAKE_EXECUTABLE_ENABLE_EXPORTS` variable.  It is provided for
backward compatibility with older CMake code, but should not be used in new
projects.


code:
CMAKE_ERROR_DEPRECATED
----------------------

Whether to issue errors for deprecated functionality.

If ``TRUE``, use of deprecated functionality will issue fatal errors.
If this variable is not set, CMake behaves as if it were set to ``FALSE``.


code:
CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
-------------------------------------------

Ask ``cmake_install.cmake`` script to error out as soon as a file with
absolute ``INSTALL DESTINATION`` is encountered.

The fatal error is emitted before the installation of the offending
file takes place.  This variable is used by CMake-generated
``cmake_install.cmake`` scripts.  If one sets this variable to ``ON`` while
running the script, it may get fatal error messages from the script.


code:
CMAKE_EXECUTABLE_ENABLE_EXPORTS
-------------------------------

.. versionadded:: 3.27

Specify whether executables export symbols for loadable modules.

This variable is used to initialize the :prop_tgt:`ENABLE_EXPORTS` target
property for executable targets when they are created by calls to the
:command:`add_executable` command.  See the property documentation for details.

This variable supersede the :variable:`CMAKE_ENABLE_EXPORTS` variable.


code:
CMAKE_EXECUTABLE_SUFFIX
-----------------------

The suffix for executables on this platform.

The suffix to use for the end of an executable filename if any, ``.exe``
on Windows.

:variable:`CMAKE_EXECUTABLE_SUFFIX_<LANG>` overrides this for
language ``<LANG>``.


code:
CMAKE_EXECUTABLE_SUFFIX_<LANG>
------------------------------

The suffix to use for the end of an executable filename of ``<LANG>``
compiler target architecture, if any.

It overrides :variable:`CMAKE_EXECUTABLE_SUFFIX` for language ``<LANG>``.


code:
CMAKE_EXECUTE_PROCESS_COMMAND_ECHO
----------------------------------

.. versionadded:: 3.15

If this variable is set to ``STDERR``, ``STDOUT`` or ``NONE`` then commands
in :command:`execute_process` calls will be printed to either stderr or
stdout or not at all.