Bump CMake requirement to 3.10, don't enable C language

[tambry]

Using a version range enables the policies up to the current version.
This fixes warnings due to deprecated policies in newer versions. Testing shows there to be no policy changes that are problematic.

A fallback is retained for versions <3.11 to emulate the version range behaviour.

[gabime]

This fixes warnings due to deprecated policies in newer versionsmo

Can you provide more details about the warnings?

[tambry]

This fixes warnings due to deprecated policies in newer versionsmo

Can you provide more details about the warnings?

For example when CMAKE_INTERPROCEDURAL_OPTIMIZATION is ON:

CMake Warning (dev) at CMakeLists.txt:148 (add_library):
  Policy CMP0069 is not set: INTERPROCEDURAL_OPTIMIZATION is enforced when
  enabled.  Run "cmake --help-policy CMP0069" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  INTERPROCEDURAL_OPTIMIZATION property will be ignored for target 'spdlog'.
This warning is for project developers.  Use -Wno-dev to suppress it.

[gabime]

I am concerned it would be hard to test new features that might be affected by policy. It would mean testing on the full range of policies instead of just 3.11

[tambry]

It would mean testing on the full range of policies instead of just 3.11

The current code is equivalent to 3.2...3.11 anyway. Per your thinking you're either already testing that range currently, which I doubt, or it'd be sufficient to simply test with 3.18.

[gabime]

Right, but now it would be worse. The range of possible policies would be 3.2...3.11 and 3.12..3.18

[tambry]

Sure, but I don't see why testing with CMake 3.18 wouldn't suffice? It'd cover all the policies.

Alternatively, it would in my opinion be sensible to bump the minimum to something more recent. LLVM very recently bumped the minimum to 3.13 for the next release.

[gabime]

It'd cover all the policies.
Are you sure? Does a given cmake policy is always backward compatible with all previous ones?

[tambry]

Are you sure? Does a given cmake policy is always backward compatible with all previous ones?

Good point, it's not that guaranteed that'd be the case. But that's unlikely and even more unlikely to affect spdlog, since spdlog's use of CMake isn't very weird.

Running CMake with -Wdev on spdlog still reveals CMP0069 as the only policy to be affected by bumping the CMake policy range to 3.2...3.18. I see no harm in this bump. If there are issues someone will report them and we'll be more ready for the time we bump the minimum version due to having testing with the newer policies enabled.

[gabime]

If minimum version 3.13 is good enough for llvm it is certainly good enough for me. Lets just raise it to 3.13

[tambry]

I've changed the PR to instead bump the CMake requirement to 3.13.

I also added another commit to not enable the C language in CMake. That doesn't seem to be necessary and not enabling C results in a significant initial configure time speedup.

[gabime]

Actually it is necessary under some platforms. see #1442

[tambry]

Actually it is necessary under some platforms. see #1442

I believe that has been fixed in CMake 3.4 by this commit, which changed FindThreads to work when the C language isn't enabled.

[gabime]

oh. good to know

[gabime]

on second thought. 3.13 seems bit too aggressive to me. especially since major distros still use older versions (http://lists.llvm.org/pipermail/llvm-dev/2020-April/140585.html)

[tambry]

How about CMake 3.10 then? That'd allow removing the policy setting and C language enablement workarounds.

[gabime]

Sounds better. Thanks!

[tambry]

Already updated the PR for CMake 3.10. 😉