parent
f622ac3441
commit
cf677c087a
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -0,0 +1,11 @@
|
|||||||
|
CMAKE_CROSSCOMPILING_EMULATOR
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
.. include:: ENV_VAR.txt
|
||||||
|
|
||||||
|
The default value for :variable:`CMAKE_CROSSCOMPILING_EMULATOR` when there
|
||||||
|
is no explicit configuration given on the first run while creating a new
|
||||||
|
build tree. On later runs in an existing build tree the value persists in
|
||||||
|
the cache as :variable:`CMAKE_CROSSCOMPILING_EMULATOR`.
|
@ -0,0 +1,19 @@
|
|||||||
|
HIPHOSTCXX
|
||||||
|
-----------
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
.. include:: ENV_VAR.txt
|
||||||
|
|
||||||
|
Preferred executable for compiling host code when compiling ``HIP``
|
||||||
|
language files with the NVIDIA CUDA Compiler. Will only be used by CMake
|
||||||
|
on the first configuration to determine ``HIP`` host compiler, after which
|
||||||
|
the value for ``HIPHOSTCXX`` is stored in the cache as
|
||||||
|
:variable:`CMAKE_HIP_HOST_COMPILER <CMAKE_<LANG>_HOST_COMPILER>`.
|
||||||
|
|
||||||
|
This environment variable is primarily meant for use with projects that
|
||||||
|
enable ``HIP`` as a first-class language.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
Ignored when using :ref:`Visual Studio Generators`.
|
@ -1,57 +1,8 @@
|
|||||||
Visual Studio 11 2012
|
Visual Studio 11 2012
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
Deprecated. Generates Visual Studio 11 (VS 2012) project files.
|
Removed. This once generated Visual Studio 11 2012 project files, but
|
||||||
|
the generator has been removed since CMake 3.28. It is still possible
|
||||||
.. note::
|
to build with VS 11 2012 tools using the :generator:`Visual Studio 14 2015`
|
||||||
This generator is deprecated and will be removed in a future version
|
(or above) generator with :variable:`CMAKE_GENERATOR_TOOLSET` set to ``v110``,
|
||||||
of CMake. It will still be possible to build with VS 11 2012 tools
|
or by using the :generator:`NMake Makefiles` generator.
|
||||||
using the :generator:`Visual Studio 12 2013` (or above) generator
|
|
||||||
with :variable:`CMAKE_GENERATOR_TOOLSET` set to ``v110``, or by
|
|
||||||
using the :generator:`NMake Makefiles` generator.
|
|
||||||
|
|
||||||
For compatibility with CMake versions prior to 3.0, one may specify this
|
|
||||||
generator using the name "Visual Studio 11" without the year component.
|
|
||||||
|
|
||||||
Project Types
|
|
||||||
^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
Only Visual C++ and C# projects may be generated (and Fortran with
|
|
||||||
Intel compiler integration). Other types of projects (JavaScript,
|
|
||||||
Database, Website, etc.) are not supported.
|
|
||||||
|
|
||||||
Platform Selection
|
|
||||||
^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
The default target platform name (architecture) is ``Win32``.
|
|
||||||
|
|
||||||
.. versionadded:: 3.1
|
|
||||||
The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set, perhaps
|
|
||||||
via the :option:`cmake -A` option, to specify a target platform
|
|
||||||
name (architecture). For example:
|
|
||||||
|
|
||||||
* ``cmake -G "Visual Studio 11 2012" -A Win32``
|
|
||||||
* ``cmake -G "Visual Studio 11 2012" -A x64``
|
|
||||||
* ``cmake -G "Visual Studio 11 2012" -A ARM``
|
|
||||||
* ``cmake -G "Visual Studio 11 2012" -A <WinCE-SDK>``
|
|
||||||
(Specify a target platform matching a Windows CE SDK name.)
|
|
||||||
|
|
||||||
For compatibility with CMake versions prior to 3.1, one may specify
|
|
||||||
a target platform name optionally at the end of the generator name.
|
|
||||||
This is supported only for:
|
|
||||||
|
|
||||||
``Visual Studio 11 2012 Win64``
|
|
||||||
Specify target platform ``x64``.
|
|
||||||
|
|
||||||
``Visual Studio 11 2012 ARM``
|
|
||||||
Specify target platform ``ARM``.
|
|
||||||
|
|
||||||
``Visual Studio 11 2012 <WinCE-SDK>``
|
|
||||||
Specify target platform matching a Windows CE SDK name.
|
|
||||||
|
|
||||||
Toolset Selection
|
|
||||||
^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
The ``v110`` toolset that comes with Visual Studio 11 2012 is selected by
|
|
||||||
default. The :variable:`CMAKE_GENERATOR_TOOLSET` option may be set, perhaps
|
|
||||||
via the :option:`cmake -T` option, to specify another toolset.
|
|
||||||
|
@ -0,0 +1,74 @@
|
|||||||
|
.. cmake-manual-description: CMake C++ Modules Support Reference
|
||||||
|
|
||||||
|
cmake-cxxmodules(7)
|
||||||
|
*******************
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
C++ 20 introduced the concept of "modules" to the language. The design
|
||||||
|
requires build systems to order compilations among each other to satisfy
|
||||||
|
``import`` statements reliably. CMake's implementation asks the compiler
|
||||||
|
to scan source files for module dependencies during the build, collates
|
||||||
|
scanning results to infer ordering constraints, and tells the build tool
|
||||||
|
how to dynamically update the build graph.
|
||||||
|
|
||||||
|
Scanning Control
|
||||||
|
================
|
||||||
|
|
||||||
|
Whether or not sources get scanned for C++ module usage is dependent on the
|
||||||
|
following queries. The first query that provides a yes/no answer is used.
|
||||||
|
|
||||||
|
- If the source file belongs to a file set of type ``CXX_MODULES``, it will
|
||||||
|
be scanned.
|
||||||
|
- If the target does not use at least C++ 20, it will not be scanned.
|
||||||
|
- If the source file is not the language ``CXX``, it will not be scanned.
|
||||||
|
- If the :prop_sf:`CXX_SCAN_FOR_MODULES` source file property is set, its
|
||||||
|
value will be used.
|
||||||
|
- If the :prop_tgt:`CXX_SCAN_FOR_MODULES` target property is set, its value
|
||||||
|
will be used. Set the :variable:`CMAKE_CXX_SCAN_FOR_MODULES` variable
|
||||||
|
to initialize this property on all targets as they are created.
|
||||||
|
- Otherwise, the source file will be scanned if the compiler and generator
|
||||||
|
support scanning. See policy :policy:`CMP0155`.
|
||||||
|
|
||||||
|
Compiler Support
|
||||||
|
================
|
||||||
|
|
||||||
|
Compilers which CMake natively supports module dependency scanning include:
|
||||||
|
|
||||||
|
* MSVC toolset 14.34 and newer (provided with Visual Studio 17.4 and newer)
|
||||||
|
* LLVM/Clang 16.0 and newer
|
||||||
|
* GCC 14 (for the in-development branch, after 2023-09-20) and newer
|
||||||
|
|
||||||
|
Generator Support
|
||||||
|
=================
|
||||||
|
|
||||||
|
The list of generators which support scanning sources for C++ modules include:
|
||||||
|
|
||||||
|
- :generator:`Ninja`
|
||||||
|
- :generator:`Ninja Multi-Config`
|
||||||
|
- :generator:`Visual Studio 17 2022`
|
||||||
|
|
||||||
|
Limitations
|
||||||
|
-----------
|
||||||
|
|
||||||
|
There are a number of known limitations of the current C++ module support in
|
||||||
|
CMake. This does not document known limitations or bugs in compilers as these
|
||||||
|
can change over time.
|
||||||
|
|
||||||
|
For all generators:
|
||||||
|
|
||||||
|
- Header units are not supported.
|
||||||
|
- No builtin support for ``import std;`` or other compiler-provided modules.
|
||||||
|
|
||||||
|
For the Ninja Generators:
|
||||||
|
|
||||||
|
- ``ninja`` 1.11 or newer is required.
|
||||||
|
|
||||||
|
For the :ref:`Visual Studio Generators`:
|
||||||
|
|
||||||
|
- Only Visual Studio 2022 and MSVC toolsets 14.34 (Visual Studio
|
||||||
|
17.4) and newer.
|
||||||
|
- No support for exporting or installing BMI or module information.
|
||||||
|
- No support for compiling BMIs from ``IMPORTED`` targets with C++ modules.
|
||||||
|
- No diagnosis of using modules provided by ``PRIVATE`` sources from
|
||||||
|
``PUBLIC`` module sources.
|
@ -0,0 +1,20 @@
|
|||||||
|
CMP0152
|
||||||
|
-------
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
:command:`file(REAL_PATH)` resolves symlinks before collapsing ../ components.
|
||||||
|
|
||||||
|
In CMake 3.27 and below, :command:`file(REAL_PATH)` collapsed any ``../``
|
||||||
|
components in a path before resolving symlinks. This produced incorrect
|
||||||
|
results when the ``../`` collapsed away a symlink.
|
||||||
|
|
||||||
|
The ``OLD`` behavior for this policy is to collapse ``../`` components before
|
||||||
|
resolving symlinks.
|
||||||
|
The ``NEW`` behavior for this policy is to resolve all symlinks before
|
||||||
|
collapsing ``../`` components.
|
||||||
|
|
||||||
|
This policy was introduced in CMake version 3.28. Use the
|
||||||
|
:command:`cmake_policy` command to set it to ``OLD`` or ``NEW`` explicitly.
|
||||||
|
|
||||||
|
.. include:: DEPRECATED.txt
|
@ -0,0 +1,14 @@
|
|||||||
|
CMP0153
|
||||||
|
-------
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
The :command:`exec_program` command should not be called.
|
||||||
|
|
||||||
|
This command has long been superseded by the :command:`execute_process`
|
||||||
|
command and has been deprecated since CMake 3.0.
|
||||||
|
|
||||||
|
.. |disallowed_version| replace:: 3.28
|
||||||
|
.. include:: DISALLOWED_COMMAND.txt
|
||||||
|
|
||||||
|
.. include:: DEPRECATED.txt
|
@ -0,0 +1,59 @@
|
|||||||
|
CMP0154
|
||||||
|
-------
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
Generated files are private by default in targets using :ref:`file sets`.
|
||||||
|
|
||||||
|
CMake 3.27 and below assume that any file generated as an output or byproduct
|
||||||
|
of :command:`add_custom_command` or :command:`add_custom_target` may be a
|
||||||
|
public header file meant for inclusion by dependents' source files. This
|
||||||
|
requires :ref:`Ninja Generators` to add conservative order-only dependencies
|
||||||
|
that prevent a target's source files from compiling before custom commands
|
||||||
|
from the target's dependencies are finished, even if those custom commands
|
||||||
|
only produce sources private to their own target.
|
||||||
|
|
||||||
|
:ref:`File Sets`, introduced by CMake 3.23, provide a way to express the
|
||||||
|
visibility of generated header files. CMake 3.28 and above prefer to
|
||||||
|
assume that, in targets using file sets, generated files are private to
|
||||||
|
their own target by default. Generated public headers must be specified
|
||||||
|
as members of a ``PUBLIC`` (or ``INTERFACE``) ``FILE_SET``, typically of
|
||||||
|
type ``HEADERS``. With this information, :ref:`Ninja Generators` may omit
|
||||||
|
the above-mentioned conservative dependencies and produce more efficient
|
||||||
|
build graphs.
|
||||||
|
|
||||||
|
Additionally, if the custom command's output is a member of a file set of type
|
||||||
|
``CXX_MODULES``, it will additionally not be required to exist before
|
||||||
|
compiling other sources in the same target. Since these files should not be
|
||||||
|
included at compile time directly, they may not be implicitly required to
|
||||||
|
exist for other compilation rules.
|
||||||
|
|
||||||
|
This policy provides compatibility for projects using file sets in targets
|
||||||
|
with generated header files that have not been updated. Such projects
|
||||||
|
should be updated to express generated public headers in a file set.
|
||||||
|
For example:
|
||||||
|
|
||||||
|
.. code-block:: cmake
|
||||||
|
|
||||||
|
add_custom_command(
|
||||||
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.h
|
||||||
|
...
|
||||||
|
)
|
||||||
|
target_sources(foo
|
||||||
|
PUBLIC FILE_SET HEADERS
|
||||||
|
BASE_DIRS ${CMAKE_CURRENT_BINARY_DIR}
|
||||||
|
FILES ${CMAKE_CURRENT_BINARY_DIR}/foo.h
|
||||||
|
)
|
||||||
|
|
||||||
|
The ``OLD`` behavior for this policy is to assume generated files are
|
||||||
|
public, even in targets using file sets, and for :ref:`Ninja Generators`
|
||||||
|
to produce conservative build graphs. The ``NEW`` behavior for this
|
||||||
|
policy is to assume generated files are private in targets using file sets,
|
||||||
|
and for :ref:`Ninja Generators` to produce more efficient build graphs.
|
||||||
|
|
||||||
|
This policy was introduced in CMake version 3.28. Use the
|
||||||
|
:command:`cmake_policy` command to set it to ``OLD`` or ``NEW`` explicitly.
|
||||||
|
Unlike many policies, CMake version |release| does *not* warn
|
||||||
|
when this policy is not set and simply uses ``OLD`` behavior.
|
||||||
|
|
||||||
|
.. include:: DEPRECATED.txt
|
@ -0,0 +1,28 @@
|
|||||||
|
CMP0155
|
||||||
|
-------
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
C++ sources in targets with at least C++20 are scanned for imports
|
||||||
|
when supported.
|
||||||
|
|
||||||
|
CMake 3.27 and below assume that C++ sources do not ``import`` modules.
|
||||||
|
CMake 3.28 and above prefer to assume that C++ sources in targets using C++20
|
||||||
|
or higher might ``import`` modules, and must be scanned before compiling,
|
||||||
|
unless explicitly disabled. This policy provides compatibility for projects
|
||||||
|
that use C++20 or higher, without modules, that have not been updated to turn
|
||||||
|
off scanning, e.g., via the :variable:`CMAKE_CXX_SCAN_FOR_MODULES` variable.
|
||||||
|
See the :manual:`cmake-cxxmodules(7)` manual for more details on C++ module
|
||||||
|
support.
|
||||||
|
|
||||||
|
The ``OLD`` behavior for this policy is to assume that C++ 20 and newer
|
||||||
|
sources do not import modules. The ``NEW`` behavior for this policy is to
|
||||||
|
assume that C++ 20 and newer files may import modules if the compiler
|
||||||
|
understands how to scan for their dependencies, and need to be scanned.
|
||||||
|
|
||||||
|
This policy was introduced in CMake version 3.28. Use the
|
||||||
|
:command:`cmake_policy` command to set it to ``OLD`` or ``NEW`` explicitly.
|
||||||
|
Unlike many policies, CMake version |release| does *not* warn
|
||||||
|
when this policy is not set and simply uses ``OLD`` behavior.
|
||||||
|
|
||||||
|
.. include:: DEPRECATED.txt
|
@ -0,0 +1,7 @@
|
|||||||
|
GENERATED_RESOURCE_SPEC_FILE
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
Path to the :ref:`dynamically-generated resource spec file
|
||||||
|
<ctest-resource-dynamically-generated-spec-file>` generated by this test.
|
@ -0,0 +1,10 @@
|
|||||||
|
IMPORTED_CXX_MODULES_COMPILE_DEFINITIONS
|
||||||
|
----------------------------------------
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
Preprocessor definitions for compiling an ``IMPORTED`` target's C++ module
|
||||||
|
sources.
|
||||||
|
|
||||||
|
CMake will automatically drop some definitions that are not supported
|
||||||
|
by the native build tool.
|
@ -0,0 +1,9 @@
|
|||||||
|
IMPORTED_CXX_MODULES_COMPILE_FEATURES
|
||||||
|
-------------------------------------
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
Compiler features enabled for this ``IMPORTED`` target's C++ modules.
|
||||||
|
|
||||||
|
The value of this property is used by the generators to set the include
|
||||||
|
paths for the compiler.
|
@ -0,0 +1,9 @@
|
|||||||
|
IMPORTED_CXX_MODULES_COMPILE_OPTIONS
|
||||||
|
------------------------------------
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
List of options to pass to the compiler for this ``IMPORTED`` target's C++
|
||||||
|
modules.
|
||||||
|
|
||||||
|
.. include:: ../command/OPTIONS_SHELL.txt
|
@ -0,0 +1,10 @@
|
|||||||
|
IMPORTED_CXX_MODULES_INCLUDE_DIRECTORIES
|
||||||
|
----------------------------------------
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
List of preprocessor include file search directories when compiling C++
|
||||||
|
modules for ``IMPORTED`` targets.
|
||||||
|
|
||||||
|
The value of this property is used by the generators to set the include
|
||||||
|
paths for the compiler.
|
@ -0,0 +1,7 @@
|
|||||||
|
IMPORTED_CXX_MODULES_LINK_LIBRARIES
|
||||||
|
-----------------------------------
|
||||||
|
|
||||||
|
.. versionadded:: 3.28
|
||||||
|
|
||||||
|
List of direct dependencies to use for usage requirements for C++ modules in
|
||||||
|
the target's C++ modules.
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue