WriteCompilerDetectionHeader¶
Deprecated since version 3.20: This module is available only if policy CMP0120
is not set to NEW
. Do not use it in new code.
New in version 3.1.
This module provides the function write_compiler_detection_header()
.
This function can be used to generate a file suitable for preprocessor inclusion which contains macros to be used in source code:
write_compiler_detection_header(
FILE <file>
PREFIX <prefix>
[OUTPUT_FILES_VAR <output_files_var> OUTPUT_DIR <output_dir>]
COMPILERS <compiler> [...]
FEATURES <feature> [...]
[BARE_FEATURES <feature> [...]]
[VERSION <version>]
[PROLOG <prolog>]
[EPILOG <epilog>]
[ALLOW_UNKNOWN_COMPILERS]
[ALLOW_UNKNOWN_COMPILER_VERSIONS]
)
This generates the file <file>
with macros which all have the prefix
<prefix>
.
By default, all content is written directly to the <file>
. The
OUTPUT_FILES_VAR
may be specified to cause the compiler-specific
content to be written to separate files. The separate files are then
available in the <output_files_var>
and may be consumed by the caller
for installation for example. The OUTPUT_DIR
specifies a relative
path from the main <file>
to the compiler-specific files. For example:
write_compiler_detection_header(
FILE climbingstats_compiler_detection.h
PREFIX ClimbingStats
OUTPUT_FILES_VAR support_files
OUTPUT_DIR compilers
COMPILERS GNU Clang MSVC Intel
FEATURES cxx_variadic_templates
)
install(FILES
${CMAKE_CURRENT_BINARY_DIR}/climbingstats_compiler_detection.h
DESTINATION include
)
install(FILES
${support_files}
DESTINATION include/compilers
)
VERSION
may be used to specify the API version to be generated.
Future versions of CMake may introduce alternative APIs. A given
API is selected by any <version>
value greater than or equal
to the version of CMake that introduced the given API and less
than the version of CMake that introduced its succeeding API.
The value of the CMAKE_MINIMUM_REQUIRED_VERSION
variable is used if no explicit version is specified.
(As of CMake version 3.31.20241013-g9733ce1 there is only one API version.)
PROLOG
may be specified as text content to write at the start of the
header. EPILOG
may be specified as text content to write at the end
of the header
At least one <compiler>
and one <feature>
must be listed. Compilers
which are known to CMake, but not specified are detected and a preprocessor
#error
is generated for them. A preprocessor macro matching
<PREFIX>_COMPILER_IS_<compiler>
is generated for each compiler
known to CMake to contain the value 0
or 1
.
Possible compiler identifiers are documented with the
CMAKE_<LANG>_COMPILER_ID
variable.
Available features in this version of CMake are listed in the
CMAKE_C_KNOWN_FEATURES
and
CMAKE_CXX_KNOWN_FEATURES
global properties.
See the cmake-compile-features(7)
manual for information on
compile features.
New in version 3.2: Added MSVC
and AppleClang
compiler support.
New in version 3.6: Added Intel
compiler support.
Changed in version 3.8: The {c,cxx}_std_*
meta-features are ignored if requested.
New in version 3.8: ALLOW_UNKNOWN_COMPILERS
and ALLOW_UNKNOWN_COMPILER_VERSIONS
cause
the module to generate conditions that treat unknown compilers as simply
lacking all features. Without these options the default behavior is to
generate a #error
for unknown compilers and versions.
New in version 3.12: BARE_FEATURES
will define the compatibility macros with the name used in
newer versions of the language standard, so the code can use the new feature
name unconditionally.
Feature Test Macros¶
For each compiler, a preprocessor macro is generated matching
<PREFIX>_COMPILER_IS_<compiler>
which has the content either 0
or 1
, depending on the compiler in use. Preprocessor macros for
compiler version components are generated matching
<PREFIX>_COMPILER_VERSION_MAJOR
<PREFIX>_COMPILER_VERSION_MINOR
and <PREFIX>_COMPILER_VERSION_PATCH
containing decimal values
for the corresponding compiler version components, if defined.
A preprocessor test is generated based on the compiler version
denoting whether each feature is enabled. A preprocessor macro
matching <PREFIX>_COMPILER_<FEATURE>
, where <FEATURE>
is the
upper-case <feature>
name, is generated to contain the value
0
or 1
depending on whether the compiler in use supports the
feature:
write_compiler_detection_header(
FILE climbingstats_compiler_detection.h
PREFIX ClimbingStats
COMPILERS GNU Clang AppleClang MSVC Intel
FEATURES cxx_variadic_templates
)
#if ClimbingStats_COMPILER_CXX_VARIADIC_TEMPLATES
template<typename... T>
void someInterface(T t...) { /* ... */ }
#else
// Compatibility versions
template<typename T1>
void someInterface(T1 t1) { /* ... */ }
template<typename T1, typename T2>
void someInterface(T1 t1, T2 t2) { /* ... */ }
template<typename T1, typename T2, typename T3>
void someInterface(T1 t1, T2 t2, T3 t3) { /* ... */ }
#endif
Symbol Macros¶
Some additional symbol-defines are created for particular features for use as symbols which may be conditionally defined empty:
class MyClass ClimbingStats_FINAL
{
ClimbingStats_CONSTEXPR int someInterface() { return 42; }
};
The ClimbingStats_FINAL
macro will expand to final
if the
compiler (and its flags) support the cxx_final
feature, and the
ClimbingStats_CONSTEXPR
macro will expand to constexpr
if cxx_constexpr
is supported.
If BARE_FEATURES cxx_final
was given as argument the final
keyword
will be defined for old compilers, too.
The following features generate corresponding symbol defines and if they
are available as BARE_FEATURES
:
Feature |
Define |
Symbol |
bare |
---|---|---|---|
|
|
|
yes |
|
|
|
yes |
|
|
|
|
|
|
|
|
|
|
|
yes |
|
|
|
yes |
|
|
|
|
|
|
|
yes |
Compatibility Implementation Macros¶
Some features are suitable for wrapping in a macro with a backward compatibility implementation if the compiler does not support the feature.
When the cxx_static_assert
feature is not provided by the compiler,
a compatibility implementation is available via the
<PREFIX>_STATIC_ASSERT(COND)
and
<PREFIX>_STATIC_ASSERT_MSG(COND, MSG)
function-like macros. The macros
expand to static_assert
where that compiler feature is available, and
to a compatibility implementation otherwise. In the first form, the
condition is stringified in the message field of static_assert
. In
the second form, the message MSG
is passed to the message field of
static_assert
, or ignored if using the backward compatibility
implementation.
The cxx_attribute_deprecated
feature provides a macro definition
<PREFIX>_DEPRECATED
, which expands to either the standard
[[deprecated]]
attribute or a compiler-specific decorator such
as __attribute__((__deprecated__))
used by GNU compilers.
The cxx_alignas
feature provides a macro definition
<PREFIX>_ALIGNAS
which expands to either the standard alignas
decorator or a compiler-specific decorator such as
__attribute__ ((__aligned__))
used by GNU compilers.
The cxx_alignof
feature provides a macro definition
<PREFIX>_ALIGNOF
which expands to either the standard alignof
decorator or a compiler-specific decorator such as __alignof__
used by GNU compilers.
Feature |
Define |
Symbol |
bare |
---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A use-case which arises with such deprecation macros is the deprecation
of an entire library. In that case, all public API in the library may
be decorated with the <PREFIX>_DEPRECATED
macro. This results in
very noisy build output when building the library itself, so the macro
may be may be defined to empty in that case when building the deprecated
library:
add_library(compat_support ${srcs})
target_compile_definitions(compat_support
PRIVATE
CompatSupport_DEPRECATED=
)
Example Usage¶
Note
This section was migrated from the cmake-compile-features(7)
manual since it relies on the WriteCompilerDetectionHeader
module
which is removed by policy CMP0120
.
Compile features may be preferred if available, without creating a hard
requirement. For example, a library may provide alternative
implementations depending on whether the cxx_variadic_templates
feature is available:
#if Foo_COMPILER_CXX_VARIADIC_TEMPLATES
template<int I, int... Is>
struct Interface;
template<int I>
struct Interface<I>
{
static int accumulate()
{
return I;
}
};
template<int I, int... Is>
struct Interface
{
static int accumulate()
{
return I + Interface<Is...>::accumulate();
}
};
#else
template<int I1, int I2 = 0, int I3 = 0, int I4 = 0>
struct Interface
{
static int accumulate() { return I1 + I2 + I3 + I4; }
};
#endif
Such an interface depends on using the correct preprocessor defines for the
compiler features. CMake can generate a header file containing such
defines using the WriteCompilerDetectionHeader
module. The
module contains the write_compiler_detection_header
function which
accepts parameters to control the content of the generated header file:
write_compiler_detection_header(
FILE "${CMAKE_CURRENT_BINARY_DIR}/foo_compiler_detection.h"
PREFIX Foo
COMPILERS GNU
FEATURES
cxx_variadic_templates
)
Such a header file may be used internally in the source code of a project, and it may be installed and used in the interface of library code.
For each feature listed in FEATURES
, a preprocessor definition
is created in the header file, and defined to either 1
or 0
.
Additionally, some features call for additional defines, such as the
cxx_final
and cxx_override
features. Rather than being used in
#ifdef
code, the final
keyword is abstracted by a symbol
which is defined to either final
, a compiler-specific equivalent, or
to empty. That way, C++ code can be written to unconditionally use the
symbol, and compiler support determines what it is expanded to:
struct Interface {
virtual void Execute() = 0;
};
struct Concrete Foo_FINAL {
void Execute() Foo_OVERRIDE;
};
In this case, Foo_FINAL
will expand to final
if the
compiler supports the keyword, or to empty otherwise.
In this use-case, the project code may wish to enable a particular language
standard if available from the compiler. The CXX_STANDARD
target property may be set to the desired language standard for a particular
target, and the CMAKE_CXX_STANDARD
variable may be set to
influence all following targets:
write_compiler_detection_header(
FILE "${CMAKE_CURRENT_BINARY_DIR}/foo_compiler_detection.h"
PREFIX Foo
COMPILERS GNU
FEATURES
cxx_final cxx_override
)
# Includes foo_compiler_detection.h and uses the Foo_FINAL symbol
# which will expand to 'final' if the compiler supports the requested
# CXX_STANDARD.
add_library(foo foo.cpp)
set_property(TARGET foo PROPERTY CXX_STANDARD 11)
# Includes foo_compiler_detection.h and uses the Foo_FINAL symbol
# which will expand to 'final' if the compiler supports the feature,
# even though CXX_STANDARD is not set explicitly. The requirement of
# cxx_constexpr causes CMake to set CXX_STANDARD internally, which
# affects the compile flags.
add_library(foo_impl foo_impl.cpp)
target_compile_features(foo_impl PRIVATE cxx_constexpr)
The write_compiler_detection_header
function also creates compatibility
code for other features which have standard equivalents. For example, the
cxx_static_assert
feature is emulated with a template and abstracted
via the <PREFIX>_STATIC_ASSERT
and <PREFIX>_STATIC_ASSERT_MSG
function-macros.