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. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers