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

[Stephen Kelly]

Brad King wrote:

>> 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.

Ok. When <PUBLIC|PRIVATE> is part of it, that will be easy even if I remove 
REQUIRED.

>> 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?

Correct.

> I have
> no strong opinion on which approach is better, but here are some
> comments.
> 
> What is an example use case for optional features?

Adding a move constructor to a class. Many Qt classes have move constructors 
and they are inline and bounded by a define.

Another: Define Foo_OVERRIDE to either 'override' or nothing, depending on 
the using compiler capability.

> 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?

As far as I know, no. Things like r-value references, variadic templates etc 
would just be unavailable to the caller if not using a capable compiler. 
Things like final and override are not encoded into the ABI afaik. At least 
that seems to be the assumption Qt makes.

>>  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.

Oops, yes, you're right on both counts. I didn't re-read the previous thread 
before writing the above.

> 
>>  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.

If the intention is to define Grantlee_OVERRIDE to either 'override' or 
nothing depending on the compiler capability, and to use classes using that 
define in the interface, then it does have to be installed.

> 
>> 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.

Yes.

>> 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.

Ok.

>> 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?

I'm not sure. We might not list a feature which a compiler has, either 
because the compiler release is newer than the cmake release, or because the 
compiler is unknown to us. 

In that case, being able to use 

 list(APPEND CMAKE_CXX_COMPILER_FEATURES cxx_variadic_templates)

would be useful.

Thanks,

Steve.