[cmake] always target Windows SDK v10.x when using Visual Studio generators (fixes #6448)

[jameslamb]

Fixes #6448

Related to #5884.

Helps with #6213.

Proposes always targeting v10.x of the Windows SDK in CMake builds using the Visual Studio generators.

Notes for Reviewers

How I tested this

Building the R package, using Visual Studio 17 2022, on my Windows laptop running Windows 10 Home Edition.

Rscript build_r.R --no-build-vignettes

With rtools44 (https://cran.r-project.org/bin/windows/Rtools/rtools44/rtools.html) on PATH.

Without this change, CMake targets via 8.1 of the Windows SDK and detects the wrong Windows version.

Trying 'Visual Studio 17 2022'
-- Selecting Windows SDK version 8.1 to target Windows 6.2.9200.
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:28 (project):
-- Configuring incomplete, errors occurred!
  No CMAKE_C_COMPILER could be found.

That causes all of the Visual Studio and then the MSBuild solutions to fail, and therefore installation of the R package to fail.

With this change, it correctly targets v10 of the Windows SDK.

installing via 'install.libs.R' to C:/Users/James/Documents/R/win-library/4.4/00LOCK-lightgbm/00new/lightgbm
Trying 'Visual Studio 17 2022'
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.
-- The C compiler identification is MSVC 19.33.31630.0
-- The CXX compiler identification is MSVC 19.33.31630.0
...

References

• https://discourse.cmake.org/t/problem-differences-in-detected-default-windowssdk-on-two-different-machines/2585/6
• https://cmake.org/cmake/help/latest/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.html
• https://gitlab.kitware.com/cmake/cmake/-/issues/25413
• https://discourse.cmake.org/t/selecting-windows-sdk-8-1/7822/3
• https://stackoverflow.com/questions/73673196/python-cmake-chooses-wrong-windows-sdk-version
• https://cmake.org/cmake/help/latest/variable/CMAKE_GENERATOR_PLATFORM.html#visual-studio-platform-selection
• https://stackoverflow.com/a/59514792/3986677
• https://stackoverflow.com/a/45693321/3986677

[david-cortes]

@jameslamb Thanks for looking into this.

Some questions:

• What happens if the platform is windows 11 or windows server?
• Does lightgbm make any usage of the windows OS API that would make it require linkage to the windows SDK? As far as I am aware, all the functionalities for things like GPU, distributed training, etc. are handled by linking to external dependencies.

[jameslamb]

What happens if the platform is windows 11 or windows server?

Good question!

My understanding is that v10 of the SDK supports Windows 11 and most versions of Windows Server.

See "Supported Operating Systems" here: https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/.

For example, the R-package MSVC tests here are targeting Windows Server 2019 and Windows 2022.

https://github.com/actions/runner-images?tab=readme-ov-file#available-images

LightGBM/.github/workflows/r_package.yml

Lines 92 to 107 in 20f2092

	# Visual Studio 2019
	- os: windows-2019
	task: r-package
	compiler: MSVC
	toolchain: MSVC
	r_version: 3.6
	build_type: cmake
	container: null
	# Visual Studio 2022
	- os: windows-2022
	task: r-package
	compiler: MSVC
	toolchain: MSVC
	r_version: 4.3
	build_type: cmake
	container: null

Does lightgbm make any usage of the windows OS API that would make it require linkage to the windows SDK?

Not 100% sure (Windows-specific development is not something I have a lot of experience in), but I think that winsock2, for example, comes through the Windows SDK.

LightGBM/src/network/socket_wrapper.hpp

Lines 22 to 24 in 20f2092

	#include <winsock2.h>
	#include <ws2tcpip.h>
	#include <iphlpapi.h>

https://learn.microsoft.com/en-us/windows/win32/winsock/creating-a-basic-winsock-application

If you see some other alternative to simplify LightGBM's Windows builds here I'd welcome it.

[david-cortes]

It compiles correctly with msvc after this PR, but with some caveats: if compiling for a second time, it hangs indefinitely without issuing any message (just stuck in installing the package to build vignettes). It looks like it requires killing the whole console application and then launching a new one in order to successfully install for a second time. Not sure if it has anything to do with the changes here though.

[jameslamb]

It looks like it requires killing the whole console application and then launching a new one in order to successfully install for a second time.

Oh interesting, I haven't seen that before. I'm not sure what the cause of that might be.

You can skip building the vignettes (and therefore compiling the library twice) by passing --no-build-vignettes:

Rscript build_r.R --no-build-vignettes

We have vignette-building on by default so that the package tarball that's produced is suitable to pass to R CMD check --as-cran. But for work like #6213 where you're primarily interested in just compiling the library and using it or running the unit tests, the vignettes are unnecessary.