[cmake-developers] C++11 and target_compiler_feature proposal

[Brad King]

Hi Steve,

Thanks for working on this!

On 10/17/2013 10:28 AM, Stephen Kelly wrote:
> For the language specification, I added a prefix to each feature. This 
> matches the feature tests of clang for standard features, and it is 
> extensible to extensions with gnuxx_typeof, msvc_sealed etc.
> 
>  http://clang.llvm.org/docs/LanguageExtensions.html

Good idea.

> So far, it only supports the REQUIRED signature of the command. 
> 
> It will need to get a <PUBLIC|PRIVATE> specifier, so that the 
> INTERFACE_COMPILER_FEATURES property can be populated in PUBLIC mode. It 
> also needs to learn to process generator expressions and how to consume that 
> property.

Yes.

> Optional features with defines are not yet implemented. I was considering 
> renaming target_compiler_features to target_required_features

I think target_compiler_features is a clearer name even if it only
supports required features.  Please leave room in the signature for
future expansion to optional features just in case.

> and not using the same command for optional features. Instead I think
> it might be a good idea to have a separate command for optional features.

FWIW, I thought he optional features with macros was quite elegant.
Also that approach didn't require header generation, right?  I have
no strong opinion on which approach is better, but here are some
comments.

What is an example use case for optional features?  What if a header
file selects an available optional feature when included by a .cxx
in the package's libraries, but not when it is later included by an
application?  Might that generate an ABI mismatch?

>  write_compiler_feature_file(
>    FILENAME "${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h"
>    FEATURES cxx_static_assert gnuxx_typeof cxx_variadic_templates
>  )

IIUC this header will contain hard-coded preprocessor tests and present
the results in preprocessor symbols testable by the project.  Shouldn't
it take some kind of namespace prefix for those names?  Also this may
need the VERSION interface number previously discussed.

>  install(FILES "${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h"
>    DESTINATION include
>  )

If the header is not in the public interface it need not be installed either.

> which writes the file with appropriate content. I don't see any need to use 
> preprocessor macros for that instead of a file.

That will also simplify consuming an interface without CMake because no
magic addition of preprocessor definitions will be needed.

> I also prototyped a simple way to test clang features as reportedly 
> supported by clang itself. This won't get us all of the way there with 
> clang, as some features (such as the gnu typeof extension) do not have 
> support via __has_extension.

Neat.  I see no reason Modules/FeatureTests/clang_feature_tests.cxx
can't be just Modules/Compiler/clang_feature_tests.cxx.  For those
features not covered by __has_extension we can list them explicitly.
You'll also have to deal with cases when CMAKE_CXX_COMPILER is not
set.  It should always be set at this point but we need to fail with
a readable explanation if it is not.

> Additionally, I changed my mind on the issue of whether to bump the dialect 
> to c++11 if the compiler supports the requested feature in c++98 mode. For 
> example, cxx_variadic_templates would be in CMAKE_CXX98_COMPILER_FEATURES 
> for GCC and clang, because both support variadic templates even when using 
> the -std=c++98 dialect. This will still warn, but that's ok, I think.
> 
> Note that adding -std=c++11 is almost, but not quite, entirely source 
> compatible.

Okay.

> Any comments so far?

Should we memoize the language feature lists as std::set<> at the end of
cmGlobalGenerator::EnableLanguage to make lookup faster and avoid projects
corrupting the lists?

Thanks,
-Brad