[cmake-developers] Compiler features/extensions remaining/future issues

[Stephen Kelly]

Stephen Kelly wrote:

> Here is a dump of some notes I have accumulated regarding compile
> features.
> 

Just a few more:

10) WriteCompilerDetectionHeader content size

Already, with only two compilers supported, the header generated by 
WriteCompilerDetectionHeader is quite large when generating for all 
features. 

If that is a problem (Is it?), then a solution may be to generate something 
like:

 #if Foo_COMPILER_IS_GNU
 #include "foo_compiler_detection_gnu.hpp"
 #elif Foo_COMPILER_IS_Clang
 #include "foo_compiler_detection_clang.hpp"
 #endif

However, that would mean requiring the user to install multiple files rather 
than just one. So, it might make sense to add a new signature

 write_compiler_detection_header(
   DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/compiler_detection"
   FILE_SUFFIX "hpp"
   PREFIX Foo
   COMPILERS GNU Clang AppleClang MSVC Intel XL Cray HP SunPro
   FEATURES
     ${cxx_known_features}
 )

so users can do

 install((DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/compiler_detection/"
   DESTINATION include
 )

There are still use-cases for the single-file signature. For example, for a
project composed of multiple libraries (like Boost or KF5), each individual
library may care about only 2 or 3 compile features and each would generate
a header for only those that it needs. This doesn't actually arise for KF5
because compile feature detection is provided by Qt. For Boost, each library
depends on the Boost.Config library, so wouldn't use this either. But I 
think keeping the use-case still makes sense.


11) WriteCompilerDetectionHeader vs GenerateExportHeader

Related to the 'universal interface for features' issue, it would be 
possible to define features such as cmake_c{,xx}_hidden_visibility to 
generate content similar to what GenerateExportHeader creates. That would 
make GenerateExportHeader obsolete for compilers supported by 
WriteCompilerDetectionHeader and the <LANG>_VISIBILITY_PRESET and 
VISIBILITY_INLINES_HIDDEN target properties.

This would require a new signature like

 write_compiler_detection_header(
   FILE mytarget_compiler_detection.h
   TARGET mytarget
   COMPILERS GNU Clang
   FEATURES
     cmake_cxx_hidden_visibility
     cxx_attribute_deprecated
 )

and

 write_compiler_detection_header(
   DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/compiler_detection"
   TARGET mytarget
   COMPILERS GNU Clang
   FEATURES
     cmake_cxx_hidden_visibility
     cxx_attribute_deprecated
 )

The <target> is needed in order to know what the value of the DEFINE_SYMBOL 
target property is.


12) Platform-specific defines

We could consider adding defines such as PLATFORM_IS_UNIX, 
PLATFORM_IS_WINDOWS etc, which CMake already knows how to detect. There are 
other things which would be possible to detect too, such as architecture, OS 
etc.

This is what Boost.Predef offers, but possibly not with the same names as
CMake (I didn't check).

 https://github.com/boostorg/predef/tree/master/include/boost/predef


Thanks,

Steve.