Update to CMake 3.23.0

[henryiii]

Created by update_cmake_version.py

[henryiii]

Manylinux build issue:

CMAKE_USE_SYSTEM_LIBUV is ON but a libuv not found

[henryiii]

Ahh:

Could NOT find LibUV: Found unsuitable version "1.23.0", but required is at least "1.28.0"

[henryiii]

@thewtex, @jcfr, and @mayeut, thoughts? I believe libuv was pinned (in fbe20a9), then has been adjusted a few times, most recently in 0895db3 to only use the "old" version for old GLIBC.

manylinux1 is pretty far past EOL at this point, but it's still required for pip 9, which is the default on CentOS/RHEL 7, ubuntu 18.04, and such. If we go manylinux2010 only, then this will try to build from the SDist on these systems, rather than getting CMake 3.22 (which I'd also like to avoid people getting pinned to older versions).

[mayeut]

my 2 cents:

manylinux1 shall be replaced by manylinux2010 (or just replace the now default x86/x64 manylinux2014 build by a manylinux2010 build ?).

The source dist should probably be updated to error out on glibc < 2.12 with an error message with instructions (TBD if pinning is not wanted). This will not be enough for outdated pip and I'm not sure we can easily find out which pip is being used (maybe I'm wrong).

One recommended way might be to define the pip environment variable to only download binaries for the cmake package.

Another way would be another package kept in sync that would pin the correct cmake version if neeeded based on some heuristic (kind of like oldest-supported-numpy). e.g. we'd release one with a pin on cmake<3.23 for manylinux1 before making the release. This would however require to change build system dependencies in all downstream projects which is probably not gonna happen...

[henryiii]

There are several reasons this is bad for cmake. First, as a base build package, it will force every package using CMake to stop supporting manylinux1 whether they like it or not. This is not terrible, but manylinux1 is still receiving updates. cmake is always required at build time, so there's no way around it.

The much worse problem is that this package is not Python dependent. That means that as soon as we drop manylinux1, this will likely break many existing Python 2 and quite a few 3.6 users. Most packages have been dropping based on version number; dropping Python 3.6 & manylinux1 at the same time means you get to still ship manylinux1 to the default Python (3.6) users on CentOS 7 & Ubuntu 18.04 and the many default Python 2's. NumPy did something similar with manylinux versions & Python 3.10; they just didn't bother to ship old manylinux versions for 3.10, since there wouldn't be a point, while they did for older versions.

The solution might be just to recommend users needing manylinux1 to cap <3.23, add the SDist error for low GLibC, recommend the binary only pip flag, etc.

[twam]

Any plan/update/ETA on this topic? Looking forward to use 3.23 :)

[henryiii]

Closing in favor of #253.