[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