[cmake-developers] target_compile_features remaining issues
Philipp Moeller
bootsarehax at gmail.com
Wed Apr 2 18:35:47 EDT 2014
Stephen Kelly <steveire at gmail.com> 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
More information about the cmake-developers
mailing list