Is CMake 3.13 absolutely required right now?

[MatthewLM]

I see that the minimum required cmake has been increased to 3.13 ( #1230 #1238). I imagine this is necessary for the future but I don't see how it is needed for v0.3.1. Is it safe to reduce this back to 3.10?

The problem is that the flutter SDK recommends to remain with 3.10 for plugin authors. As mentioned when creating a new plugin:

# The Flutter tooling requires that developers have CMake 3.10 or later
# installed. You should not increase this version, as doing so will cause
# the plugin to fail to compile for some customers of the plugin.

I could choose to ignore the suggested minimum by flutter or fork the library to reduce the minimum version. Others might have a similar compatibility issue and I don't know if it was premature to increase the required minimum version yet.

[hebasto]

cc @theuni

[hebasto]

@MatthewLM

Thanks for bringing this issue to our attention!

Indeed, during our discussion in #1230 we didn't consider compatibility with the Flutter framework.

AFAICT, the only required feature is the SameMinorVersion compatibility mode in the write_basic_package_version_file() command (see https://gnusha.org/secp256k1/2023-03-08.log), which is available in CMake 3.11+.

OTOH, from flutter/flutter#52751 it follows that CMake 3.10 is required

for easy compatibility with Ubuntu 18.04

That looks outdated now. Does the Flutter project have any discussion or roadmap concerning the update of the CMake version?

[MatthewLM]

Thank you for the response. The Ubuntu 18.04 has extended support for the "Pro" users until April 2028 though I imagine that's a small minority. I can't find any discussions about increasing the required cmake version for flutter.

I doubt increasing the required cmake version for a flutter plugin to 3.13 will affect many users. It's probably only a matter of time before the flutter SDK increases the requirement, though I imagine it's not high on their priority list.

[theuni]

Hi @MatthewLM

Thanks for letting us know. Point taken about v0.3.1, though I'm afraid that would only encourage people to count on some behavior that is likely to change in order to take advantage of newer CMake. In fact, I'm going to use this as a plea to merge that PR :p

So while the bump is only superficial for now, I'd call the current situation an unfortunate mid-state between the bump and the features that take advantage of it.

For builders on older OS's, I suspect we'll continue to recommend the autotools buildsystem for quite a while. Out of curiosity, is there anything it lacks (other than convenience) that CMake allows for?

[MatthewLM]

I tried using ExternalProject_Add for the autotools build but I couldn't get it to work with the flutter CMake build on Android in particular. I was successful with using the new CMake build.

I'm going to raise the minimum CMake version to 3.13 as most users of the plugin will likely have no issue.

[theuni]

@MatthewLM I'd be happy to try to troubleshoot the ExternalProject_Add + autotools problem with you if you'd like to open a new issue.

[MatthewLM]

@theuni Thank you very much for offering to help with that problem, though upon consideration I'm happy to stick with CMake and raise the version. That shouldn't be an issue for what I'm working on, though maybe this is a somewhat broader issue for other people.

[real-or-random]

I'm going to raise the minimum CMake version to 3.13 as most users of the plugin will likely have no issue.

Thanks for being flexible. I feel that's the way to go. I totally see that it makes sense for Flutter to recommend not to have stricter requirements than the base framework. But on the other hand, 3.10 is pretty old right now, and requiring 3.13 won't affect many users.

The way we see our CMake experiment is that a) it's a more modern alternative to GNU Autotools, and b) it simply makes integration in other CMake projects easier. If we'd give up on that "modern" part, we'd lose a) unfortunately. But it's already good to see that b) works out and could lead to more adoption of the library.

And yes, 0.3.1 was a bit unfortunate. We wanted to get this release out quickly because it's a security fix, and releasing master is less of a pain backporting fixes to old releases. But I guess it was even the better choice to bump the CMake version earlier before more people start relying on the low version (as pointed out by @theuni).