[cmake-developers] target_compile_features remaining issues

[Stephen Kelly]

Brad King wrote:

> On 04/07/2014 01:04 PM, Stephen Kelly wrote:
>>>> 2) Unavailable features
>>>> The distinction between "this compiler version supports an empty subset
>>>> of the features known to CMake" and "we have not tested the features of
>>>> this version of the compiler" is not quite so easy.
>> 
>> I vaguely prefer being more explicit by using a non-feature-feature, but
>> this can be deferred for the moment anyway.
> 
> This will need to be resolved now that the initial topic is in master.
> Is this an implementation difficulty or are you just trying to decide
> what interface a project should use to detect the distinction?

Only deciding the interface.

> 
> We need to be sure that adding knowledge of features for a particular
> {id, version} combination that did not previously have them did not
> does not cause projects to stop building.  If CMake errors out only
> when it knows the compiler does not have a requested feature but not
> when it knows about no features from a {id, version} combination then
> just filling out the table could stop projects from building that
> used to happen to work.

Yes. An option would be to wrap the population of features for a compiler in 
new CMake releases, where that feature is known to previous CMake releases, 
in a CMAKE_MINIMUM_REQUIRED_VERSION check.

> I think we should reverse our earlier decision and go ahead and add
> an error whenever a feature is requested that we do not know *is*
> supported for the current {id, version}.  This will make filling out
> the feature table be monotonically decreasing in the number of error
> cases projects can encounter.  It will also encourage people to help
> make the table complete.

Yes, I think that makes sense. Such an error can be relaxed in the future if 
desired.

It might also give us something of a 'census' to find out what compilers 
people care about to use with new CMake features and fill the table. Of 
course, culture will also affect that anyway (A GNU user is more likely to 
contribute than a MSVC user, probably), so probably not so useful.

> We just need to find a reasonable path forward for projects that want
> bleeding edge features if available but also want to be able to build
> with tools for which CMake has not learned any feature tests.  Could
> these projects simply query CMAKE_CXX_COMPILE_FEATURES before making
> something a build/usage requirement?

Yes. 

 if (CMAKE_CXX_COMPILE_FEATURES)
   target_compile_features(tgt PRIVATE cxx_constexpr)
 endif()

would work.

> 
>>>> Do we need to require some kind of maintenance commitment from people
>>>> who want to add the first feature for a {compiler id, version} tuple,
>>>> like is currently required for adding new modules?
>>>
>>> I would go for my initial approach: have a compile-test for it.
>> 
>> I recall that seemed like a non-solution when this was discussed before.
>> I think the problem is that the compile-test we write may not exercise
>> all of the edge cases which may be relevant to a compiler version, such
>> as undocumented cxx_constexpr support in GNU 4.5.
> 
> IIRC Boost.Config has a script one can run to populate everything for
> a previously unseen compiler.  Perhaps we can provide something like
> that for filling out feature availability tables.

Yes, I considered adding a separate mode to the CompileFeatures test to run 
try_compiles of each source file there with each 
CMAKE_CXX*_{STANDARD,EXTENSION}_COMPILE_OPTION. That could be used to create 
a report, but not to generate the -FeatureTests.cmake file for checkin. If 
you run such a script with GNU-4.7 now, you have to figure out how to merge 
the output with the existing GNU-CXX-FeatureTests.cmake.

> I think one invariant we need to maintain is that if CMake knows any
> feature tests for a given {id, version} it needs to know all of them.

Yes. I tried to get that across in the change to cmake-developer (in my 
clone, not in next yet) 

 http://www.steveire.com/cmake-future/manual/cmake-developer.7.html#adding-compile-features

> Whenever a new known feature is added then a test for it must be
> added to all {id, version} combinations that know about any features.

Yes.

Thanks,

Steve.