Linux.pl
Opcje wyszukiwania podręcznika man:
Lista stron man zaczynających się od znaku:
A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Y   Z   ALPHA   NUM   OTHER   ALL
CMAKE-COMPILE-FEATURES(7)            CMake           CMAKE-COMPILE-FEATURES(7)

NAME
       cmake-compile-features - CMake Compile Features Reference

INTRODUCTION
       Project source code may depend on, or be conditional on, the availabil-
       ity of certain features of the compiler.   There  are  three  use-cases
       which  arise:  Compile  Feature Requirements, Optional Compile Features
       and Conditional Compilation Options.

       While features are typically specified in  programming  language  stan-
       dards,  CMake  provides a primary user interface based on granular han-
       dling of the features, not the language standard  that  introduced  the
       feature.

       The      CMAKE_C_KNOWN_FEATURES,     CMAKE_CUDA_KNOWN_FEATURES,     and
       CMAKE_CXX_KNOWN_FEATURES global properties  contain  all  the  features
       known  to  CMake,  regardless of compiler support for the feature.  The
       CMAKE_C_COMPILE_FEATURES,     CMAKE_CUDA_COMPILE_FEATURES     ,     and
       CMAKE_CXX_COMPILE_FEATURES  variables  contain all features CMake knows
       are known to the compiler, regardless of language standard  or  compile
       flags needed to use them.

       Features  known to CMake are named mostly following the same convention
       as the Clang feature test macros.  There are some exceptions,  such  as
       CMake  using cxx_final and cxx_override instead of the single cxx_over-
       ride_control used by Clang.

       Note that there are no separate compile features  properties  or  vari-
       ables  for  the OBJC or OBJCXX languages.  These are based off C or C++
       respectively, so the properties and variables for  their  corresponding
       base language should be used instead.

COMPILE FEATURE REQUIREMENTS
       Compile  feature  requirements  may  be  specified with the target_com-
       pile_features() command.  For example, if a  target  must  be  compiled
       with compiler support for the cxx_constexpr feature:

          add_library(mylib requires_constexpr.cpp)
          target_compile_features(mylib PRIVATE cxx_constexpr)

       In  processing  the requirement for the cxx_constexpr feature, cmake(1)
       will ensure that the in-use C++ compiler is capable of the feature, and
       will  add any necessary flags such as -std=gnu++11 to the compile lines
       of C++ files in the mylib target.  A FATAL_ERROR is issued if the  com-
       piler is not capable of the feature.

       The exact compile flags and language standard are deliberately not part
       of the user interface for this use-case.  CMake will compute the appro-
       priate  compile  flags to use by considering the features specified for
       each target.

       Such compile flags are added even if the compiler supports the particu-
       lar  feature  without  the flag. For example, the GNU compiler supports
       variadic templates (with a  warning)  even  if  -std=gnu++98  is  used.
       CMake adds the -std=gnu++11 flag if cxx_variadic_templates is specified
       as a requirement.

       In the above example, mylib requires cxx_constexpr when it is built it-
       self,  but  consumers of mylib are not required to use a compiler which
       supports cxx_constexpr.  If the interface of  mylib  does  require  the
       cxx_constexpr  feature (or any other known feature), that may be speci-
       fied with the PUBLIC or  INTERFACE  signatures  of  target_compile_fea-
       tures():

          add_library(mylib requires_constexpr.cpp)
          # cxx_constexpr is a usage-requirement
          target_compile_features(mylib PUBLIC cxx_constexpr)

          # main.cpp will be compiled with -std=gnu++11 on GNU for cxx_constexpr.
          add_executable(myexe main.cpp)
          target_link_libraries(myexe mylib)

       Feature  requirements  are evaluated transitively by consuming the link
       implementation.  See cmake-buildsystem(7) for more on transitive behav-
       ior of build properties and usage requirements.

   Requiring Language Standards
       In projects that use a large number of commonly available features from
       a particular  language  standard  (e.g.  C++  11)  one  may  specify  a
       meta-feature  (e.g.  cxx_std_11)  that  requires use of a compiler mode
       that is at minimum aware of that standard, but could be greater.   This
       is  simpler than specifying all the features individually, but does not
       guarantee the existence of any particular feature.  Diagnosis of use of
       unsupported features will be delayed until compile time.

       For  example,  if  C++  11  features are used extensively in a projects
       header files, then clients must use a compiler mode  that  is  no  less
       than C++ 11.  This can be requested with the code:

          target_compile_features(mylib PUBLIC cxx_std_11)

       In this example, CMake will ensure the compiler is invoked in a mode of
       at-least  C++  11  (or  C++  14,  C++  17,  ),  adding  flags  such  as
       -std=gnu++11  if  necessary.   This  applies to sources within mylib as
       well as any dependents (that may include headers from mylib).

   Availability of Compiler Extensions
       Because the CXX_EXTENSIONS target property is ON by default, CMake uses
       extended variants of language dialects by default, such as -std=gnu++11
       instead of -std=c++11.  That target property may be set to OFF  to  use
       the  non-extended  variant of the dialect flag.  Note that because most
       compilers enable extensions by default, this could  expose  cross-plat-
       form bugs in user code or in the headers of third-party dependencies.

OPTIONAL COMPILE FEATURES
       Compile features may be preferred if available, without creating a hard
       requirement.  For example, a library may provides alternative implemen-
       tations  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 pa-
       rameters 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  cre-
       ated 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 e.

CMAKE-COMPILE-FEATURES(7)            CMake           CMAKE-COMPILE-FEATURES(7)

NAME
       cmake-compile-features - CMake Compile Features Reference

INTRODUCTION
       Project source code may depend on, or be conditional on, the availabil-
       ity  of  certain  features  of the compiler.  There are three use-cases
       which arise: Compile Feature Requirements,  Optional  Compile  Features
       and Conditional Compilation Options.

       While  features  are  typically specified in programming language stan-
       dards, CMake provides a primary user interface based on  granular  han-
       dling  of  the  features, not the language standard that introduced the
       feature.

       The     CMAKE_C_KNOWN_FEATURES,     CMAKE_CUDA_KNOWN_FEATURES,      and
       CMAKE_CXX_KNOWN_FEATURES  global  properties  contain  all the features
       known to CMake, regardless of compiler support for  the  feature.   The
       CMAKE_C_COMPILE_FEATURES,     CMAKE_CUDA_COMPILE_FEATURES     ,     and
       CMAKE_CXX_COMPILE_FEATURES variables contain all features  CMake  knows
       are  known  to the compiler, regardless of language standard or compile
       flags needed to use them.

       Features known to CMake are named mostly following the same  convention
       as  the  Clang feature test macros.  There are some exceptions, such as
       CMake using cxx_final and cxx_override instead of the single  cxx_over-
       ride_control used by Clang.

       Note  that  there  are no separate compile features properties or vari-
       ables for the OBJC or OBJCXX languages.  These are based off C  or  C++
       respectively,  so  the properties and variables for their corresponding
       base language should be used instead.

COMPILE FEATURE REQUIREMENTS
       Compile feature requirements may  be  specified  with  the  target_com-
       pile_features()  command.   For  example,  if a target must be compiled
       with compiler support for the cxx_constexpr feature:

          add_library(mylib requires_constexpr.cpp)
          target_compile_features(mylib PRIVATE cxx_constexpr)

       In processing the requirement for the cxx_constexpr  feature,  cmake(1)
       will ensure that the in-use C++ compiler is capable of the feature, and
       will add any necessary flags such as -std=gnu++11 to the compile  lines
       of  C++ files in the mylib target.  A FATAL_ERROR is issued if the com-
       piler is not capable of the feature.

       The exact compile flags and language standard are deliberately not part
       of the user interface for this use-case.  CMake will compute the appro-
       priate compile flags to use by considering the features  specified  for
       each target.

       Such compile flags are added even if the compiler supports the particu-
       lar feature without the flag. For example, the  GNU  compiler  supports
       variadic  templates  (with  a  warning)  even  if -std=gnu++98 is used.
       CMake adds the -std=gnu++11 flag if cxx_variadic_templates is specified
       as a requirement.

       In the above example, mylib requires cxx_constexpr when it is built it-
       self, but consumers of mylib are not required to use a  compiler  which
       supports  cxx_constexpr.   If  the  interface of mylib does require the
       cxx_constexpr feature (or any other known feature), that may be  speci-
       fied  with  the  PUBLIC  or INTERFACE signatures of target_compile_fea-
       tures():

          add_library(mylib requires_constexpr.cpp)
          # cxx_constexpr is a usage-requirement
          target_compile_features(mylib PUBLIC cxx_constexpr)

          # main.cpp will be compiled with -std=gnu++11 on GNU for cxx_constexpr.
          add_executable(myexe main.cpp)
          target_link_libraries(myexe mylib)

       Feature requirements are evaluated transitively by consuming  the  link
       implementation.  See cmake-buildsystem(7) for more on transitive behav-
       ior of build properties and usage requirements.

   Requiring Language Standards
       In projects that use a large number of commonly available features from
       a  particular  language  standard  (e.g.  C++  11)  one  may  specify a
       meta-feature (e.g. cxx_std_11) that requires use  of  a  compiler  mode
       that  is at minimum aware of that standard, but could be greater.  This
       is simpler than specifying all the features individually, but does  not
       guarantee the existence of any particular feature.  Diagnosis of use of
       unsupported features will be delayed until compile time.

       For example, if C++ 11 features are  used  extensively  in  a  projects
       header  files,  then  clients  must use a compiler mode that is no less
       than C++ 11.  This can be requested with the code:

          target_compile_features(mylib PUBLIC cxx_std_11)

       In this example, CMake will ensure the compiler is invoked in a mode of
       at-least  C++  11  (or  C++  14,  C++  17,  ),  adding  flags  such  as
       -std=gnu++11 if necessary.  This applies to  sources  within  mylib  as
       well as any dependents (that may include headers from mylib).

   Availability of Compiler Extensions
       Because the CXX_EXTENSIONS target property is ON by default, CMake uses
       extended variants of language dialects by default, such as -std=gnu++11
       instead  of  -std=c++11.  That target property may be set to OFF to use
       the non-extended variant of the dialect flag.  Note that  because  most
       compilers  enable  extensions by default, this could expose cross-plat-
       form bugs in user code or in the headers of third-party dependencies.

OPTIONAL COMPILE FEATURES
       Compile features may be preferred if available, without creating a hard
       requirement.  For example, a

3.18.4                        September 13, 2021     CMAKE-COMPILE-FEATURES(7)

Czas wygenerowania: 0.00042 sek.


Created with the man page lookup class by Andrew Collington.
Based on a C man page viewer by Vadim Pavlov
Unicode soft-hyphen fix (as used by RedHat) by Dan Edwards
Some optimisations by Eli Argon
Caching idea and code contribution by James Richardson

Copyright © 2003-2025 Linux.pl
Hosted by Hosting Linux.pl