Chore: Bump CMake, CI workflows

[marcizhu]

This PR bumps the minimum required CMake version from 3.1 to 3.31, the last supported version for CMake 3.x. It also updates the CI workflows and fixes some issues with code coverage:

• Drops Clang 11 from CI builds, as the compiler is quite old and apt wasn't finding it on the default repos
• Uses lcov instead of gcov for collecting coverage data, gcov wasn't working for some reason
• Uses the official codecov GitHub Action instead of the Codecov Uploader script, as it's newer and better supported

In general I think these changes should be pretty safe and should allow using the library on newer versions of CMake. Let me know if you want any changes!

[marcizhu]

Hey @kthohr! Would it be possible to get this PR merged? Do you want any changes? I have some dependencies that are failing to build due to CMake being unsupported.

Thanks in advance! 😄

[BartolomeyKant]

Why the 3.31 was selected? It is better to provide the range like #54 did.

[marcizhu]

@BartolomeyKant v3.31 is the last v3.x version supported by CMake as it has since moved into v4.x, which I assume contains breaking changes and upgrading might not be trivial. The CMakeLists.txt file in this repo doesn't use any feature specific to v3.10...v3.31 so there's no point in requesting an older version if you don't need anything from it.

Also, v3.31.0 was released on November 6th, 2024 (more than a year ago). I would understand adding a range or asking for an older version if this was released relatively recently, but after a year all major package managers, CI providers, etc... will support v3.31.0 for sure, as CMake is already well into v4.2 already.

[BartolomeyKant]

Also, v3.31.0 was released on November 6th, 2024 (more than a year ago). I would understand adding a range or asking for an older version if this was released relatively recently, but after a year all major package managers, CI providers, etc... will support v3.31.0 for sure, as CMake is already well into v4.2 already.

I understand your point.
But we live in real world. For example my project is building with platformio and its tool-chain for esp32 fixed on cmake 3.16 by default.

And since it doesn't use any features specific to >3.10 why limit it only with newer versions?

[marcizhu]

I also understand your point but v3.16.0 was released on November 26th, 2019. That was more than 6 years ago... I don't think there is any benefit in supporting 6+ year old software when probably Kitware themselves don't support it anymore and would recommend upgrading to a newer version. Again, I understand supporting 1-2 year old versions but I don't see a point going back more than 6 years ago.

If the ESP32 toolchain is fixed on CMake v3.16 I would strongly suggest opening an issue with them to get that upgraded. I don't think every single project out there should support a version that was released more than half a decade ago just because they didn't upgrade CMake after all these years.

Besides, this is open source software, you can always change the minimum version for your project if you can't use v3.31.0 for whatever reason. Of course this is up to the maintainer of this repo to decide, but in my opinion 1+ year of backwards-compatibility should be more than enough for 99.9% of projects yet not too much where there might be missing features, dropped support, etc.