[cmake-developers] target_compile_features remaining issues

[Rolf Eike Beer]

Am Freitag, 28. März 2014, 16:16:49 schrieb Stephen Kelly:
> Hi,
> 
> The target_compile_features topic in my clone is almost ready to merge to
> next.
> 
> Here are some remaining issues to discuss:
> 
> 1) Extensions
> 

> I propose ignoring the granularity of XL and letting the user be more
> granular if they wish (I think there's also granularity available with GNU
> flags).

I think just go for whatever is needed to get the requested features, if it 
enables more then it will be this way.

> 2) Unavailable features
> 
> There will be some set of features supported by CMake.
> 
> Each tuple of {compiler id, compiler version, lang standard, extensions}
> will have some subset of those features available.
> 
> If CMake is executed on a target which requires a particular feature, and
> CMake knows that the particular feature is not supported by the compiler id
> and version (with any extra flags), CMake reports an error.
> 
> Recording that a {compiler id, compiler version} supports a particular
> feature is fairly easy, as is done in my topic already.
> 
> 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.

Maybe "if (DEFINED var)" vs. "if(VAR)"?

> 3) Maintenance
> 
> If CMake learns a cxx_partial_template_specialization feature in the future,
> the cxx_no_features feature would be removed for MSVC71 and
> cxx_partial_template_specialization added. That means that someone
> (preferably with direct access to MSVC71) needs to maintain the list of
> features for that {compiler id, compiler version} as the list of features
> known to CMake grows.
> 
> This is more difficult maintenance to do for compilers which are no longer
> widely available or common.

[...]

> 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. If the 
compiler features are unknown (i.e. the compiler support var is undefined) then 
just run the compiletests and use whatever is the outcome. Have a way to force 
CMake to use the tests instead of the hardcoded list. This will allow things 
to work in case of new CMake versions (new features) with a feature list that 
was not updated or if some vendor fscks up their version stuff. It would also 
be a good testcase: everything hardcoded must be detected, otherwise our list 
is broken (or the testcase).

> 4) All available features use-case

No idea. You are already far beyond what I would need with your stuff.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140403/b4bc6762/attachment-0002.sig>