[cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

Robert Maynard robert.maynard at kitware.com
Tue Jan 3 13:43:40 EST 2017


I doubt the change to cmPolicies.h would do as you expect, as the
logic to set a policy to a given state ( OLD,WARN,NEW ) is actually
done by cmPolicies::ApplyPolicyVersion.

Now as far as how Qt5 is operating, personally I agree it would be
nice that the module would provide better warnings or errors, instead
they have just documented these issues on their cmake page:
http://doc.qt.io/qt-5/cmake-manual.html

On Tue, Jan 3, 2017 at 12:12 PM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:
>
>> It is the responsibility of the project to understand what components
>> of CMake they require, and correctly specify a cmake_minimum required
>> that satisfies all those requirements. In this case to use compile
>> features you need a minimum of 3.0 which also automatically enables
>> policy 25.
>
> I agree with you in a way, but in reality it would be up to end users and packagers to feed back that information to an unknown number of projects and convince them why it's necessary to comply with the request. That's just not doable.
> It would be a lot easier if the policy could be set at a central location, in this case in the Qt module invoking the test that fails.
>
>
> And it's CMake's responsibility to generate useful error messages, and where possible provide a hint for the fix.
>
>> You can explicitly do both of those things currently see:
>> https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html
>
> Ah, thanks. I take it one can also change a line in cmPolicies.h:
>
>   SELECT(POLICY, CMP0025, "Compiler id for Apple Clang is now AppleClang.",   \
>          3, 0, 0, cmPolicies::NEW)                                           \
>
> ?
>
> R.


More information about the cmake-developers mailing list