Conan-center-index: [bug] Most of cmake files are not compatible to cmake 2.8

[uilianries]

This comment changes the course of the cmake files in CCI:

Test package uses CXX_STANDARD property, which is available since 3.1.

True, indeed, the CMake documentation only shows CXX_STANDARD at fist time in 3.1. As you know, we largely use set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD 11) for force -std=c++11, however it doesn't work for CMake 2.8.

I tried a small example with CMake 2.8.12. Cmake didn't add the cxx flag and didn't show any warning, and didn't fail. Old compiler like GCC5 will fail, because the test_package won't receive the desired cxx flags when building.

Now we have a bug inserted in all cmake files which require C++>=11, but users are not complaining about, why? Probably no one is running CMake 2.8 ...

Also, the Conan issue https://github.com/conan-io/conan/issues/7064 demonstrates that no one requested 2.8 for compatibility, so we have one more good argument.

I propose the promotion of cmake version to 3.1 as minimal supported.
For now we have a version soup in CCI, sometimes 2.8, 3.0 or 3.1. We have to check which feature the cmake file is using and compare if it's supported or not by tha cmake version. IHMO, we should be more focused in the recipe when reviewing, not in cmake particularities.

If we adopt keeping 2.8, we will need to use the old set(CMAKE_CXX_FLAGS ...) to append the c++ standard.

/cc @conan-io/barbarians

[Croydon]

Overall it would be good to follow whatever Conan 2.0 decides.

On the other hand, most projects require a higher CMake version than your few lines of CMake code anyway

---

The example you linked above is about opencolorio. The packaged version 1.1.1 actually supports >= CMake 2.8 right now. But the master branch already increased it to CMake >= 3.11 https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/b843e98f119f9160bb866d4485c2413fedc2392e/CMakeLists.txt#L4

[Croydon]

That said, raising the overall minimum from CMake 2.8 to 3.1 should be absolutely fine. We probably could also rise it higher, but when we do not get any good advantage from it there is also no reason to raise it even higher.

3.1 sounds good to me.

[uilianries]

Not exactly related to opencolorio, but the test package, which is generic. CXX_STANDARD is CMake 3.

[SSE4]

I think in test_package it's totally okay to use CMake 3 or higher - we know which one is installed in our environment.
for package itself, we should inject CMake code carefully, to avoid accidentally changing CMake version required to use the library.

[jgsogo]

I think so, CMake 2.x is no longer in the main CMake docs. We should pay attention to the one required by libraries, but the test_package can use whatever is needed.

[dmn-star]

The libs should use modern CMake (>3.0, better >3.11) nowadays.
https://cliutils.gitlab.io/modern-cmake/

[uilianries]

What about the CMake wrapper? Doesn't make any sense keeping 2.8 and for test package 3.1

[jgsogo]

CMakeLists.txt wrapper should have the same version requirement (or lower) as the library itself.

test_package/CMakeLists.txt and the CMakeLists.txt wrapper are used in two different CMake executions, never together, they are not related.

[uilianries]

Okay, makes sense.

[SSE4]

@uilianries so, to clarify, is anything here to be done/fixed?

[uilianries]

@SSE4 Yes, you should consider:

• Using CMake 3.1 for test_package/CMakeLists.txt. You could use 2.8 when CXX_STANDARD is not listed, but I think using 3.1 for any recipe creates a pattern
• For CMake Wrapper keeps 2.8, but if you need to force CXX_STANDARD, set 3.1

[SSE4]

@uilianries is it something which could be (easily) tested by hook? e.g. scanning for CXX_STANDARD and cmake_minimum_required?
any other CMake features on your radar that we should carefully use?

[uilianries]

@SSE4 Yes, totally! That's an excellent idea. I can do that.

[uilianries]

@SSE4 Yes, totally. I just created https://github.com/conan-io/hooks/pull/213 which should be able to detect your description.