[ci] Require CMake 3.28 and replace FetchContent_Populate with FetchContent_MakeAvailable

[StrikerRUS]

Fix warning:

CMake Warning (dev) at C:/Program Files/CMake/share/cmake-3.30/Modules/FetchContent.cmake:1953 (message):
  Calling FetchContent_Populate(OpenCL-Headers) is deprecated, call
  FetchContent_MakeAvailable(OpenCL-Headers) instead.  Policy CMP0169 can be
  set to OLD to allow FetchContent_Populate(OpenCL-Headers) to be called
  directly for now, but the ability to call it with declared details will be
  removed completely in a future version.
Call Stack (most recent call first):
  cmake/IntegratedOpenCL.cmake:19 (FetchContent_Populate)
  CMakeLists.txt:207 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Populated OpenCL Headers
CMake Warning (dev) at C:/Program Files/CMake/share/cmake-3.30/Modules/FetchContent.cmake:1953 (message):
  Calling FetchContent_Populate(OpenCL-ICD-Loader) is deprecated, call
  FetchContent_MakeAvailable(OpenCL-ICD-Loader) instead.  Policy CMP0169 can
  be set to OLD to allow FetchContent_Populate(OpenCL-ICD-Loader) to be
  called directly for now, but the ability to call it with declared details
  will be removed completely in a future version.
Call Stack (most recent call first):
  cmake/IntegratedOpenCL.cmake:28 (FetchContent_Populate)
  CMakeLists.txt:207 (include)

https://dev.azure.com/lightgbm-ci/lightgbm-ci/_build/results?buildId=16653&view=logs&j=ea56812e-e7ae-55d0-6abc-4a217857fa9f&t=76df8fa4-5d0e-54b7-f50a-d34a7285da97&l=555

FetchContent_MakeAvailable
New in version 3.14.
https://cmake.org/cmake/help/latest/module/FetchContent.html#command:fetchcontent_makeavailable

LightGBM requires CMake >= 3.18.

LightGBM/CMakeLists.txt

Line 26 in f8ec57b

cmake_minimum_required(VERSION 3.18)

[StrikerRUS]

At the moment, FetchContent_MakeAvailable performs add_subdirectory() on a CMake-using project's root.
https://gitlab.kitware.com/cmake/cmake/-/issues/22904

https://github.com/pupnp/pupnp/blob/a797db77abce24f8b4d231785b3b53fd3571fb52/cmake/CmDaB.cmake#L48-L58

https://github.com/wiredtiger/wiredtiger/blob/ae9445d14c33c245d0d6eead556cc360fdd60851/CMakeLists.txt#L120-L133

[StrikerRUS]

Or we can bump minimum required version.

[jameslamb]

I support just increasing the project-wide minimum CMake version (in both CMakeLists.txt and pyproject.toml) to 3.28.

I like this advice from https://cliutils.gitlab.io/modern-cmake/chapters/intro/installing.html.

Your CMake version should be newer than your compiler. It should be newer than the libraries you are using (especially Boost). New versions work better for everyone.

If you have a built in copy of CMake, it isn't special or customized for your system. You can easily install a new one instead, either on the system level or the user level. Feel free to instruct your users here if they complain about a CMake requirement being set too high.

It's true that 3.28.0 has only been out for 8 months (https://github.com/Kitware/CMake/releases/tag/v3.28.0), but it's already in wide use.

• for Mac users, Homebrew and macports already have v3.30.0
• for Windows users, Chocolatey has v3.30.0 (link) and CMake official binaries have v3.30.0 (link)

The biggest disruption would be for Linux users. If you use apt-get install cmake on Ubuntu 22.04 today, you'll get v3.22.1. See the table at the bottom of https://cliutils.gitlab.io/modern-cmake/chapters/intro/installing.html or at https://repology.org/project/cmake/versions.

Linux users on distros with older versions would have to either install it a different way (like with pip or conda) or like this:

LightGBM/docker/dockerfile-cli

Lines 19 to 22 in f8ec57b

	RUN curl -L -o cmake.sh https://github.com/Kitware/CMake/releases/download/v3.29.2/cmake-3.29.2-linux-x86_64.sh && \
	chmod +x cmake.sh && \
	sh ./cmake.sh --prefix=/usr/local --skip-license && \
	rm cmake.sh

I don't think that's too bad... especially since to build the Python package specifically, scikit-build-core will handle automatically pip-installing cmake if a new-enough version is not found.

And I don't think this would just be for the benefit of integrated OpenCL wheels... there are lots of other benefits we'd get by upgrading to a newer minimum version. See https://cliutils.gitlab.io/modern-cmake/chapters/intro/newcmake.html.

If you feel that this is too much of a risk, then I'd support changing the minimum in CMakeLists.txt conditionally, like

if(__INTEGRATE_OPENCL)
  cmake_minimum_required(VERSION 3.18)
else()
  cmake_minimum_required(VERSION 3.28)
endif()

[StrikerRUS]

Thanks a lot for your opinion and especially for the link to short version of CMake Changelog!

scikit-build-core will handle automatically pip-installing cmake if a new-enough version is not found.

Cool feature of scikit-build-core! 👍

I'll go ahead and bump CMake version. Due to the lack of working hands here, I think it's OK to bump version unconditionally.

[jameslamb]

Thanks for fixing this!

I think we should increase the minimum CMake version instead of having different codepaths for different versions. I left 2 different forms of that suggestion in a comment here.

[jameslamb]

I support just increasing the project-wide minimum CMake version (in both CMakeLists.txt and pyproject.toml) to 3.28.

I like this advice from https://cliutils.gitlab.io/modern-cmake/chapters/intro/installing.html.

Your CMake version should be newer than your compiler. It should be newer than the libraries you are using (especially Boost). New versions work better for everyone.

If you have a built in copy of CMake, it isn't special or customized for your system. You can easily install a new one instead, either on the system level or the user level. Feel free to instruct your users here if they complain about a CMake requirement being set too high.

It's true that 3.28.0 has only been out for 8 months (https://github.com/Kitware/CMake/releases/tag/v3.28.0), but it's already in wide use.

• for Mac users, Homebrew and macports already have v3.30.0
• for Windows users, Chocolatey has v3.30.0 (link) and CMake official binaries have v3.30.0 (link)

The biggest disruption would be for Linux users. If you use apt-get install cmake on Ubuntu 22.04 today, you'll get v3.22.1. See the table at the bottom of https://cliutils.gitlab.io/modern-cmake/chapters/intro/installing.html or at https://repology.org/project/cmake/versions.

Linux users on distros with older versions would have to either install it a different way (like with pip or conda) or like this:

LightGBM/docker/dockerfile-cli

Lines 19 to 22 in f8ec57b

	RUN curl -L -o cmake.sh https://github.com/Kitware/CMake/releases/download/v3.29.2/cmake-3.29.2-linux-x86_64.sh && \
	chmod +x cmake.sh && \
	sh ./cmake.sh --prefix=/usr/local --skip-license && \
	rm cmake.sh

I don't think that's too bad... especially since to build the Python package specifically, scikit-build-core will handle automatically pip-installing cmake if a new-enough version is not found.

And I don't think this would just be for the benefit of integrated OpenCL wheels... there are lots of other benefits we'd get by upgrading to a newer minimum version. See https://cliutils.gitlab.io/modern-cmake/chapters/intro/newcmake.html.

If you feel that this is too much of a risk, then I'd support changing the minimum in CMakeLists.txt conditionally, like

if(__INTEGRATE_OPENCL)
  cmake_minimum_required(VERSION 3.18)
else()
  cmake_minimum_required(VERSION 3.28)
endif()

Significant refactor of initial idea

[jameslamb]

Thanks! Totally support this.

[StrikerRUS]

@jameslamb Thanks for your review! I'm sorry for pushing after your review, but it's a tiny non-controversial change that just removes code duplication by extracting CMake version into a variable. CI is green after this change, so I'm very confident in it and would like to merge this PR without one more round of reviews. Feel free to drop a comment and I'll revert this change in a follow up PR.

[jameslamb]

Totally fine! I agree with that change.