Stephen Kelly <[email protected]> writes: > Hi, > > The target_compile_features topic in my clone is almost ready to merge to > next. [...snipped rest of the message...]
Hi Stephen, I'm not sure how this feature would fit in any CMake build system I currently maintain. How does it improve upon the current #ifdef tables provided by e.g. Boost.Config? How does it improve over C++14 __has_feature and __has_include? Also, I wont be able to drop Boost.Config (or my own configuration tables) when this feature arrives because users of my library without CMake should still get header-files configured for their compiler. I think this is also missing the common work-around macros (MY_LIBRARY_CONSTEXPR, MY_LIBRARY_LIBRARY_OVERRIDE, etc.) which are necessary to write code that works on multiple standards. Maybe I'm missing what this feature is supposed to achieve, but I can't see how this would serve my needs. What I would find useful if I could use CMake to write a configuration header with a customized prefix. write_compiler_configuration_header(my_lib output_path) and the resulting header would contain the entire #ifdef for feature availability. Of course, when a compiler feature is a hard requirement of a target (currently it often isn't) encoding it in the build system would be nice to have. Cheers, Philipp -- 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
