This commit is contained in:
kleuter
2023-11-01 21:39:10 +01:00
parent 5c4154eda2
commit 94b1c5907b
3387 changed files with 0 additions and 0 deletions

View File

@ -0,0 +1,9 @@
ABSTRACT
--------
Is this source file an abstract class.
A property on a source file that indicates if the source file
represents a class that is abstract. This only makes sense for
languages that have a notion of an abstract class and it is only used
by some tools that wrap classes into other languages.

View File

@ -0,0 +1,22 @@
AUTORCC_OPTIONS
---------------
Additional options for ``rcc`` when using :prop_tgt:`AUTORCC`
This property holds additional command line options which will be used when
``rcc`` is executed during the build via :prop_tgt:`AUTORCC`, i.e. it is equivalent to the
optional ``OPTIONS`` argument of the :module:`qt4_add_resources() <FindQt4>` macro.
By default it is empty.
The options set on the ``.qrc`` source file may override
:prop_tgt:`AUTORCC_OPTIONS` set on the target.
EXAMPLE
^^^^^^^
.. code-block:: cmake
# ...
set_property(SOURCE resources.qrc PROPERTY AUTORCC_OPTIONS "--compress;9")
# ...

View File

@ -0,0 +1,23 @@
AUTOUIC_OPTIONS
---------------
Additional options for ``uic`` when using :prop_tgt:`AUTOUIC`
This property holds additional command line options
which will be used when ``uic`` is executed during the build via
:prop_tgt:`AUTOUIC`, i.e. it is equivalent to the optional ``OPTIONS``
argument of the :module:`qt4_wrap_ui() <FindQt4>` macro.
By default it is empty.
The options set on the ``.ui`` source file may override
:prop_tgt:`AUTOUIC_OPTIONS` set on the target.
EXAMPLE
^^^^^^^
.. code-block:: cmake
# ...
set_property(SOURCE widget.ui PROPERTY AUTOUIC_OPTIONS "--no-protection")
# ...

View File

@ -0,0 +1,32 @@
COMPILE_DEFINITIONS
-------------------
Preprocessor definitions for compiling a source file.
The ``COMPILE_DEFINITIONS`` property may be set to a semicolon-separated
list of preprocessor definitions using the syntax ``VAR`` or ``VAR=value``.
Function-style definitions are not supported. CMake will
automatically escape the value correctly for the native build system
(note that CMake language syntax may require escapes to specify some
values). This property may be set on a per-configuration basis using
the name ``COMPILE_DEFINITIONS_<CONFIG>`` where ``<CONFIG>`` is an upper-case
name (ex. ``COMPILE_DEFINITIONS_DEBUG``).
CMake will automatically drop some definitions that are not supported
by the native build tool. Xcode does not support per-configuration
definitions on source files.
.. versionadded:: 3.26
Any leading ``-D`` on an item will be removed.
.. include:: /include/COMPILE_DEFINITIONS_DISCLAIMER.txt
Contents of ``COMPILE_DEFINITIONS`` may use :manual:`cmake-generator-expressions(7)`
with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
manual for available expressions. However, :generator:`Xcode`
does not support per-config per-source settings, so expressions
that depend on the build configuration are not allowed with that
generator.
Generator expressions should be preferred instead of setting the alternative per-configuration
property.

View File

@ -0,0 +1,10 @@
COMPILE_DEFINITIONS_<CONFIG>
----------------------------
Ignored. See CMake Policy :policy:`CMP0043`.
Per-configuration preprocessor definitions on a source file.
This is the configuration-specific version of :prop_tgt:`COMPILE_DEFINITIONS`.
Note that :generator:`Xcode` does not support per-configuration source
file flags so this property will be ignored by the :generator:`Xcode` generator.

View File

@ -0,0 +1,22 @@
COMPILE_FLAGS
-------------
Additional flags to be added when compiling this source file.
The ``COMPILE_FLAGS`` property, managed as a string, sets additional compiler
flags used that will be added to the list of compile flags when this source
file builds. The flags will be added after target-wide flags (except in
some cases not supported by the :generator:`Visual Studio 9 2008` generator).
Use :prop_sf:`COMPILE_DEFINITIONS` to pass additional preprocessor definitions.
Contents of ``COMPILE_FLAGS`` may use "generator expressions"
with the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)`
manual for available expressions. However, :generator:`Xcode`
does not support per-config per-source settings, so expressions
that depend on the build configuration are not allowed with that
generator.
.. note::
This property has been superseded by the :prop_sf:`COMPILE_OPTIONS` property.

View File

@ -0,0 +1,35 @@
COMPILE_OPTIONS
---------------
.. versionadded:: 3.11
List of additional options to pass to the compiler.
This property holds a :ref:`semicolon-separated list <CMake Language Lists>`
of options and will be added to the list of compile flags when this source
file builds. The options will be added after target-wide options (except in
some cases not supported by the :generator:`Visual Studio 9 2008` generator).
Contents of ``COMPILE_OPTIONS`` may use "generator expressions" with the
syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual
for available expressions. However, :generator:`Xcode`
does not support per-config per-source settings, so expressions
that depend on the build configuration are not allowed with that
generator.
Usage example:
.. code-block:: cmake
set_source_files_properties(foo.cpp PROPERTIES COMPILE_OPTIONS "-Wno-unused-parameter;-Wno-missing-field-initializer")
Related properties:
* Prefer this property over :prop_sf:`COMPILE_FLAGS`.
* Use :prop_sf:`COMPILE_DEFINITIONS` to pass additional preprocessor definitions.
* Use :prop_sf:`INCLUDE_DIRECTORIES` to pass additional include directories.
Related commands:
* :command:`add_compile_options` for directory-wide settings
* :command:`target_compile_options` for target-specific settings

View File

@ -0,0 +1,23 @@
CXX_SCAN_FOR_MODULES
--------------------
.. versionadded:: 3.26
``CXX_SCAN_FOR_MODULES`` is a boolean specifying whether CMake will scan the
source for C++ module dependencies. See also the
:prop_tgt:`CXX_SCAN_FOR_MODULES` for target-wide settings.
When this property is set ``ON``, CMake will scan the source at build time and
add module dependency information to the compile line as necessary. When this
property is set ``OFF``, CMake will not scan the source at build time. When
this property is unset, the :prop_tgt:`CXX_SCAN_FOR_MODULES` property is
consulted.
Note that scanning is only performed if C++20 or higher is enabled for the
target and the source uses the ``CXX`` language. Scanning for modules in
sources belonging to file sets of type ``CXX_MODULES`` is always performed.
.. note ::
This setting is meaningful only when experimental support for C++ modules
has been enabled by the ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API`` gate.

View File

@ -0,0 +1,8 @@
EXTERNAL_OBJECT
---------------
If set to true then this is an object file.
If this property is set to ``True`` then the source file is really an
object file and should not be compiled. It will still be linked into
the target though.

View File

@ -0,0 +1,12 @@
Fortran_FORMAT
--------------
Set to ``FIXED`` or ``FREE`` to indicate the Fortran source layout.
This property tells CMake whether a given Fortran source file uses
fixed-format or free-format. CMake will pass the corresponding format flag
to the compiler. Consider using the target-wide :prop_tgt:`Fortran_FORMAT`
property if all source files in a target share the same format.
.. note:: For some compilers, ``NAG``, ``PGI`` and ``Solaris Studio``,
setting this to ``OFF`` will have no effect.

View File

@ -0,0 +1,19 @@
Fortran_PREPROCESS
------------------
.. versionadded:: 3.18
Control whether the Fortran source file should be unconditionally preprocessed.
If unset or empty, rely on the compiler to determine whether the file
should be preprocessed. If explicitly set to ``OFF`` then the file
does not need to be preprocessed. If explicitly set to ``ON``, then
the file does need to be preprocessed as part of the compilation step.
When using the :generator:`Ninja` generator, all source files are
first preprocessed in order to generate module dependency
information. Setting this property to ``OFF`` will make ``Ninja``
skip this step.
Consider using the target-wide :prop_tgt:`Fortran_PREPROCESS` property
if all source files in a target need to be preprocessed.

View File

@ -0,0 +1,48 @@
GENERATED
---------
Is this source file generated as part of the build or CMake process.
.. versionchanged:: 3.20
The GENERATED source file property is now visible in all directories.
Tells the internal CMake engine that a source file is generated by an outside
process such as another build step, or the execution of CMake itself.
This information is then used to exempt the file from any existence or
validity checks.
Any file that is
- created by the execution of commands such as
:command:`add_custom_command` which run during the build
- listed as one of the ``BYPRODUCTS`` of an :command:`add_custom_command`
or :command:`add_custom_target` command, or
- created by a CMake ``AUTOGEN`` operation such as :prop_tgt:`AUTOMOC`,
:prop_tgt:`AUTORCC`, or :prop_tgt:`AUTOUIC`
will be marked with the ``GENERATED`` property.
When a generated file created as the ``OUTPUT`` of an
:command:`add_custom_command` command is explicitly listed as a source file
for any target in the same directory scope (which usually means the same
``CMakeLists.txt`` file), CMake will automatically create a dependency to
make sure the file is generated before building that target.
The :ref:`Makefile Generators` will remove ``GENERATED`` files during
``make clean``.
Generated sources may be hidden in some IDE tools, while in others they might
be shown. For the special case of sources generated by CMake's :prop_tgt:`AUTOMOC`,
:prop_tgt:`AUTORCC` or :prop_tgt:`AUTOUIC` functionality, the
:prop_gbl:`AUTOGEN_SOURCE_GROUP`, :prop_gbl:`AUTOMOC_SOURCE_GROUP`,
:prop_gbl:`AUTORCC_SOURCE_GROUP` and :prop_gbl:`AUTOUIC_SOURCE_GROUP` target
properties may influence where the generated sources are grouped in the project's
file lists.
.. note::
Starting with CMake 3.20 the ``GENERATED`` source file property can be set
and retrieved from any directory scope. It is an all-or-nothing property.
It also can no longer be removed or unset if it was set to ``TRUE``. Policy
:policy:`CMP0118` was introduced to allow supporting the ``OLD`` behavior
for some time.

View File

@ -0,0 +1,24 @@
HEADER_FILE_ONLY
----------------
Is this source file only a header file.
A property on a source file that indicates if the source file is a
header file with no associated implementation. This is set
automatically based on the file extension and is used by CMake to
determine if certain dependency information should be computed.
By setting this property to ``ON``, you can disable compilation of
the given source file, even if it should be compiled because it is
part of the library's/executable's sources.
This is useful if you have some source files which you somehow
pre-process, and then add these pre-processed sources via
:command:`add_library` or :command:`add_executable`. Normally, in IDE,
there would be no reference of the original sources, only of these
pre-processed sources. So by setting this property for all the original
source files to ``ON``, and then either calling :command:`add_library`
or :command:`add_executable` while passing both the pre-processed
sources and the original sources, or by using :command:`target_sources`
to add original source files will do exactly what would one expect, i.e.
the original source files would be visible in IDE, and will not be built.

View File

@ -0,0 +1,20 @@
INCLUDE_DIRECTORIES
-------------------
.. versionadded:: 3.11
List of preprocessor include file search directories.
This property holds a :ref:`semicolon-separated list <CMake Language Lists>` of paths
and will be added to the list of include directories when this
source file builds. These directories will take precedence over directories
defined at target level except for :generator:`Xcode` generator due to technical
limitations.
Relative paths should not be added to this property directly.
Contents of ``INCLUDE_DIRECTORIES`` may use "generator expressions" with
the syntax ``$<...>``. See the :manual:`cmake-generator-expressions(7)` manual
for available expressions. However, :generator:`Xcode` does not support
per-config per-source settings, so expressions that depend on the build
configuration are not allowed with that generator.

View File

@ -0,0 +1,9 @@
KEEP_EXTENSION
--------------
Make the output file have the same extension as the source file.
If this property is set then the file extension of the output file
will be the same as that of the source file. Normally the output file
extension is computed based on the language of the source file, for
example ``.cxx`` will go to a ``.o`` extension.

View File

@ -0,0 +1,8 @@
LABELS
------
Specify a list of text labels associated with a source file.
This property has meaning only when the source file is listed in a
target whose ``LABELS`` property is also set. No other semantics are
currently specified.

View File

@ -0,0 +1,17 @@
LANGUAGE
--------
Specify the programming language in which a source file is written.
A property that can be set to indicate what programming language the
source file is. If it is not set the language is determined based on
the file extension. Typical values are ``CXX`` (i.e. C++), ``C``,
``CSharp``, ``CUDA``, ``Fortran``, ``HIP``, ``ISPC``, and ``ASM``. Setting
this property for a file means this file will be compiled, unless
:prop_sf:`HEADER_FILE_ONLY` is set.
.. versionchanged:: 3.20
Setting this property causes the source file to be compiled as the
specified language, using explicit flags if possible. Previously it
only caused the specified language's compiler to be used.
See policy :policy:`CMP0119`.

View File

@ -0,0 +1,7 @@
LOCATION
--------
The full path to a source file.
A read only property on a SOURCE FILE that contains the full path to
the source file.

View File

@ -0,0 +1,30 @@
MACOSX_PACKAGE_LOCATION
-----------------------
Place a source file inside a Application Bundle
(:prop_tgt:`MACOSX_BUNDLE`), Core Foundation Bundle (:prop_tgt:`BUNDLE`),
or Framework Bundle (:prop_tgt:`FRAMEWORK`). It is applicable for macOS
and iOS.
Executable targets with the :prop_tgt:`MACOSX_BUNDLE` property set are
built as macOS or iOS application bundles on Apple platforms. Shared
library targets with the :prop_tgt:`FRAMEWORK` property set are built as
macOS or iOS frameworks on Apple platforms. Module library targets with
the :prop_tgt:`BUNDLE` property set are built as macOS ``CFBundle`` bundles
on Apple platforms. Source files listed in the target with this property
set will be copied to a directory inside the bundle or framework content
folder specified by the property value. For macOS Application Bundles the
content folder is ``<name>.app/Contents``. For macOS Frameworks the
content folder is ``<name>.framework/Versions/<version>``. For macOS
CFBundles the content folder is ``<name>.bundle/Contents`` (unless the
extension is changed). See the :prop_tgt:`PUBLIC_HEADER`,
:prop_tgt:`PRIVATE_HEADER`, and :prop_tgt:`RESOURCE` target properties for
specifying files meant for ``Headers``, ``PrivateHeaders``, or
``Resources`` directories.
If the specified location is equal to ``Resources``, the resulting location
will be the same as if the :prop_tgt:`RESOURCE` property had been used. If
the specified location is a sub-folder of ``Resources``, it will be placed
into the respective sub-folder. Note: For iOS Apple uses a flat bundle layout
where no ``Resources`` folder exist. Therefore CMake strips the ``Resources``
folder name from the specified location.

View File

@ -0,0 +1,21 @@
OBJECT_DEPENDS
--------------
Additional files on which a compiled object file depends.
Specifies a :ref:`semicolon-separated list <CMake Language Lists>` of full-paths to
files on which any object files compiled from this source file depend.
On :ref:`Makefile Generators` and the :generator:`Ninja` generator an
object file will be recompiled if any of the named files is newer than it.
:ref:`Visual Studio Generators` and the :generator:`Xcode` generator
cannot implement such compilation dependencies.
This property need not be used to specify the dependency of a source
file on a generated header file that it includes. Although the
property was originally introduced for this purpose, it is no longer
necessary. If the generated header file is created by a custom
command in the same target as the source file, the automatic
dependency scanning process will recognize the dependency. If the
generated header file is created by another target, an inter-target
dependency should be created with the :command:`add_dependencies`
command (if one does not already exist due to linking relationships).

View File

@ -0,0 +1,12 @@
OBJECT_OUTPUTS
--------------
Additional outputs for a :generator:`Ninja` or :ref:`Makefile Generators` rule.
Additional outputs created by compilation of this source file. If any
of these outputs is missing the object will be recompiled. This is
supported only on the :generator:`Ninja` and :ref:`Makefile Generators`
and will be ignored on other generators.
This property supports
:manual:`generator expressions <cmake-generator-expressions(7)>`.

View File

@ -0,0 +1,19 @@
SKIP_AUTOGEN
------------
.. versionadded:: 3.8
Exclude the source file from :prop_tgt:`AUTOMOC`, :prop_tgt:`AUTOUIC` and
:prop_tgt:`AUTORCC` processing (for Qt projects).
For finer exclusion control see :prop_sf:`SKIP_AUTOMOC`,
:prop_sf:`SKIP_AUTOUIC` and :prop_sf:`SKIP_AUTORCC`.
EXAMPLE
^^^^^^^
.. code-block:: cmake
# ...
set_property(SOURCE file.h PROPERTY SKIP_AUTOGEN ON)
# ...

View File

@ -0,0 +1,17 @@
SKIP_AUTOMOC
------------
.. versionadded:: 3.8
Exclude the source file from :prop_tgt:`AUTOMOC` processing (for Qt projects).
For broader exclusion control see :prop_sf:`SKIP_AUTOGEN`.
EXAMPLE
^^^^^^^
.. code-block:: cmake
# ...
set_property(SOURCE file.h PROPERTY SKIP_AUTOMOC ON)
# ...

View File

@ -0,0 +1,17 @@
SKIP_AUTORCC
------------
.. versionadded:: 3.8
Exclude the source file from :prop_tgt:`AUTORCC` processing (for Qt projects).
For broader exclusion control see :prop_sf:`SKIP_AUTOGEN`.
EXAMPLE
^^^^^^^
.. code-block:: cmake
# ...
set_property(SOURCE file.qrc PROPERTY SKIP_AUTORCC ON)
# ...

View File

@ -0,0 +1,22 @@
SKIP_AUTOUIC
------------
.. versionadded:: 3.8
Exclude the source file from :prop_tgt:`AUTOUIC` processing (for Qt projects).
``SKIP_AUTOUIC`` can be set on C++ header and source files and on
``.ui`` files.
For broader exclusion control see :prop_sf:`SKIP_AUTOGEN`.
EXAMPLE
^^^^^^^
.. code-block:: cmake
# ...
set_property(SOURCE file.h PROPERTY SKIP_AUTOUIC ON)
set_property(SOURCE file.cpp PROPERTY SKIP_AUTOUIC ON)
set_property(SOURCE widget.ui PROPERTY SKIP_AUTOUIC ON)
# ...

View File

@ -0,0 +1,42 @@
SKIP_LINTING
------------
.. versionadded:: 3.27
This property allows you to exclude a specific source file
from the linting process. The linting process involves running
tools such as :prop_tgt:`<LANG>_CPPLINT`, :prop_tgt:`<LANG>_CLANG_TIDY`,
:prop_tgt:`<LANG>_CPPCHECK`, and :prop_tgt:`<LANG>_INCLUDE_WHAT_YOU_USE`
on the source files, as well as compiling header files as part of
:prop_tgt:`VERIFY_INTERFACE_HEADER_SETS`. By setting ``SKIP_LINTING`` on a
source file, the mentioned linting tools will not be executed for that
particular file.
Example
^^^^^^^
Consider a C++ project that includes multiple source files,
such as ``main.cpp``, ``things.cpp``, and ``generatedBindings.cpp``.
In this example, you want to exclude the ``generatedBindings.cpp``
file from the linting process. To achieve this, you can utilize
the ``SKIP_LINTING`` property with the :command:`set_source_files_properties`
command as shown below:
.. code-block:: cmake
add_executable(MyApp main.cpp things.cpp generatedBindings.cpp)
set_source_files_properties(generatedBindings.cpp PROPERTIES
SKIP_LINTING ON
)
In the provided code snippet, the ``SKIP_LINTING`` property is set to true
for the ``generatedBindings.cpp`` source file. As a result, when the linting
tools specified by :prop_tgt:`<LANG>_CPPLINT`, :prop_tgt:`<LANG>_CLANG_TIDY`,
:prop_tgt:`<LANG>_CPPCHECK`, or :prop_tgt:`<LANG>_INCLUDE_WHAT_YOU_USE`
are executed, they will skip analyzing the ``generatedBindings.cpp`` file.
By using the ``SKIP_LINTING`` property, you can selectively exclude specific
source files from the linting process. This allows you to focus the
linting tools on the relevant parts of your project, enhancing the efficiency
and effectiveness of the linting workflow.

View File

@ -0,0 +1,15 @@
SKIP_PRECOMPILE_HEADERS
-----------------------
.. versionadded:: 3.16
Is this source file skipped by :prop_tgt:`PRECOMPILE_HEADERS` feature.
This property helps with build problems that one would run into
when using the :prop_tgt:`PRECOMPILE_HEADERS` feature.
One example would be the usage of Objective-C (``*.m``) files, and
Objective-C++ (``*.mm``) files, which lead to compilation failure
because they are treated (in case of Ninja / Makefile generator)
as C, and CXX respectively. The precompile headers are not
compatible between languages.

View File

@ -0,0 +1,13 @@
SKIP_UNITY_BUILD_INCLUSION
--------------------------
.. versionadded:: 3.16
Setting this property to true ensures the source file will be skipped by
unity builds when its associated target has its :prop_tgt:`UNITY_BUILD`
property set to true. The source file will instead be compiled on its own
in the same way as it would with unity builds disabled.
This property helps with "ODR (One definition rule)" problems where combining
a particular source file with others might lead to build errors or other
unintended side effects.

View File

@ -0,0 +1,8 @@
SYMBOLIC
--------
Is this just a name for a rule.
If ``SYMBOLIC`` (boolean) is set to ``True`` the build system will be informed
that the source file is not actually created on disk but instead used
as a symbolic name for a build rule.

View File

@ -0,0 +1,7 @@
Swift_DEPENDENCIES_FILE
-----------------------
.. versionadded:: 3.15
This property sets the path for the Swift dependency file (swiftdeps) for the
source. If one is not specified, it will default to ``<OBJECT>.swiftdeps``.

View File

@ -0,0 +1,6 @@
Swift_DIAGNOSTICS_FILE
----------------------
.. versionadded:: 3.15
This property controls where the Swift diagnostics are serialized.

View File

@ -0,0 +1,7 @@
UNITY_GROUP
-----------
.. versionadded:: 3.18
This property controls which *bucket* the source will be part of when
the :prop_tgt:`UNITY_BUILD_MODE` is set to ``GROUP``.

View File

@ -0,0 +1,8 @@
VS_COPY_TO_OUT_DIR
------------------
.. versionadded:: 3.8
Sets the ``<CopyToOutputDirectory>`` tag for a source file in a
Visual Studio project file. Valid values are ``Never``, ``Always``
and ``PreserveNewest``.

View File

@ -0,0 +1,22 @@
VS_CSHARP_<tagname>
-------------------
.. versionadded:: 3.8
Visual Studio and CSharp source-file-specific configuration.
Tell the :manual:`Visual Studio generators <cmake-generators(7)>`
to set the source file tag ``<tagname>``
to a given value in the generated Visual Studio CSharp
project. Ignored on other generators and languages. This property
can be used to define dependencies between source files or set any
other Visual Studio specific parameters.
Example usage:
.. code-block:: cmake
set_source_files_properties(<filename>
PROPERTIES
VS_CSHARP_DependentUpon <other file>
VS_CSHARP_SubType "Form")

View File

@ -0,0 +1,14 @@
VS_DEPLOYMENT_CONTENT
---------------------
.. versionadded:: 3.1
Mark a source file as content for deployment with a Windows Phone or
Windows Store application when built with a
:manual:`Visual Studio generators <cmake-generators(7)>`.
The value must evaluate to either ``1`` or ``0`` and may use
:manual:`generator expressions <cmake-generator-expressions(7)>`
to make the choice based on the build configuration.
The ``.vcxproj`` file entry for the source file will be
marked either ``DeploymentContent`` or ``ExcludedFromBuild``
for values ``1`` and ``0``, respectively.

View File

@ -0,0 +1,11 @@
VS_DEPLOYMENT_LOCATION
----------------------
.. versionadded:: 3.1
Specifies the deployment location for a content source file with a Windows
Phone or Windows Store application when built
with a :manual:`Visual Studio generators <cmake-generators(7)>`.
This property is only applicable when using :prop_sf:`VS_DEPLOYMENT_CONTENT`.
The value represent the path relative to the app package and applies to all
configurations.

View File

@ -0,0 +1,8 @@
VS_INCLUDE_IN_VSIX
------------------
.. versionadded:: 3.8
Boolean property to specify if the file should be included within a
VSIX (Visual Studio Integration Extension) extension package.
This is needed for development of Visual Studio extensions.

View File

@ -0,0 +1,10 @@
VS_RESOURCE_GENERATOR
---------------------
.. versionadded:: 3.8
This property allows to specify the resource generator to be used
on this file. It defaults to ``PublicResXFileCodeGenerator`` if
not set.
This property only applies to C# projects.

View File

@ -0,0 +1,25 @@
VS_SETTINGS
-----------
.. versionadded:: 3.18
Set any item metadata on a file.
.. versionadded:: 3.22
This property is honored for all source file types.
Previously it worked only for non-built files.
Takes a list of ``Key=Value`` pairs. Tells the Visual Studio generator to set
``Key`` to ``Value`` as item metadata on the file.
For example:
.. code-block:: cmake
set_property(SOURCE file.hlsl PROPERTY VS_SETTINGS "Key=Value" "Key2=Value2")
will set ``Key`` to ``Value`` and ``Key2`` to ``Value2`` on the
``file.hlsl`` item as metadata.
:manual:`Generator expressions <cmake-generator-expressions(7)>` are supported.

View File

@ -0,0 +1,8 @@
VS_SHADER_DISABLE_OPTIMIZATIONS
-------------------------------
.. versionadded:: 3.11
Disable compiler optimizations for an ``.hlsl`` source file. This adds the
``-Od`` flag to the command line for the FxCompiler tool. Specify the value
``true`` for this property to disable compiler optimizations.

View File

@ -0,0 +1,8 @@
VS_SHADER_ENABLE_DEBUG
----------------------
.. versionadded:: 3.11
Enable debugging information for an ``.hlsl`` source file. This adds the
``-Zi`` flag to the command line for the FxCompiler tool. Specify the value
``true`` to generate debugging information for the compiled shader.

View File

@ -0,0 +1,7 @@
VS_SHADER_ENTRYPOINT
--------------------
.. versionadded:: 3.1
Specifies the name of the entry point for the shader of a ``.hlsl`` source
file.

View File

@ -0,0 +1,6 @@
VS_SHADER_FLAGS
---------------
.. versionadded:: 3.2
Set additional Visual Studio shader flags of a ``.hlsl`` source file.

View File

@ -0,0 +1,7 @@
VS_SHADER_MODEL
---------------
.. versionadded:: 3.1
Specifies the shader model of a ``.hlsl`` source file. Some shader types can
only be used with recent shader models

View File

@ -0,0 +1,8 @@
VS_SHADER_OBJECT_FILE_NAME
--------------------------
.. versionadded:: 3.12
Specifies a file name for the compiled shader object file for an ``.hlsl``
source file. This adds the ``-Fo`` flag to the command line for the FxCompiler
tool.

View File

@ -0,0 +1,7 @@
VS_SHADER_OUTPUT_HEADER_FILE
----------------------------
.. versionadded:: 3.10
Set filename for output header file containing object code of a ``.hlsl``
source file.

View File

@ -0,0 +1,6 @@
VS_SHADER_TYPE
--------------
.. versionadded:: 3.1
Set the Visual Studio shader type of a ``.hlsl`` source file.

View File

@ -0,0 +1,7 @@
VS_SHADER_VARIABLE_NAME
-----------------------
.. versionadded:: 3.10
Set name of variable in header file containing object code of a ``.hlsl``
source file.

View File

@ -0,0 +1,7 @@
VS_TOOL_OVERRIDE
----------------
.. versionadded:: 3.7
Override the default Visual Studio tool that will be applied to the source file
with a new tool not based on the extension of the file.

View File

@ -0,0 +1,9 @@
VS_XAML_TYPE
------------
.. versionadded:: 3.3
Mark a Extensible Application Markup Language (XAML) source file
as a different type than the default ``Page``.
The most common usage would be to set the default ``App.xaml`` file as
``ApplicationDefinition``.

View File

@ -0,0 +1,11 @@
WRAP_EXCLUDE
------------
Exclude this source file from any code wrapping techniques.
Some packages can wrap source files into alternate languages to
provide additional functionality.
For example, C++ code can be wrapped into Java or Python, using SWIG.
If ``WRAP_EXCLUDE`` is set to ``True``, that indicates that this
source file should not be wrapped.

View File

@ -0,0 +1,10 @@
XCODE_EXPLICIT_FILE_TYPE
------------------------
.. versionadded:: 3.1
Set the :generator:`Xcode` ``explicitFileType`` attribute on its reference to a
source file. CMake computes a default based on file extension but
can be told explicitly with this property.
See also :prop_sf:`XCODE_LAST_KNOWN_FILE_TYPE`.

View File

@ -0,0 +1,13 @@
XCODE_FILE_ATTRIBUTES
---------------------
.. versionadded:: 3.7
Add values to the :generator:`Xcode` ``ATTRIBUTES`` setting on its reference to a
source file. Among other things, this can be used to set the role on
a ``.mig`` file::
set_source_files_properties(defs.mig
PROPERTIES
XCODE_FILE_ATTRIBUTES "Client;Server"
)

View File

@ -0,0 +1,11 @@
XCODE_LAST_KNOWN_FILE_TYPE
--------------------------
.. versionadded:: 3.1
Set the :generator:`Xcode` ``lastKnownFileType`` attribute on its reference to
a source file. CMake computes a default based on file extension but
can be told explicitly with this property.
See also :prop_sf:`XCODE_EXPLICIT_FILE_TYPE`, which is preferred
over this property if set.