Support building for Windows using 'onecore' libraires instead of legacy kernel32.lib
The current "Windows-MSVC.cmake" has logic for picking various combinations of default system libraires. For WINDOWS_STORE
it uses the umbrella library "WindowsApp.lib", for (now legacy) WINDOWS_PHONE
it uses "WindowsPhone.lib", and otherwise it uses various combinations of "kernel32.lib".
This allows projects to easily target classic Windows desktop and UWP, but makes it challenging to target "OneCore" variants like Windows 10 only, Xbox One, and Xbox Series X|S. The main issue here is that for those platforms, they have other umbrella libraries but removing kernel32.lib from the link is essential for correctness.
VS 2022 Update 2 added the ability to provide a specific property CoreLibrariesDependencies
which allows a project to set its own core libraries specifically to address the scenario. For example, setting it to 'onecore_apiset.lib' or 'onecore.lib'.
Doing this with CMake in a systematic way is challenging, so I'm looking for a better solution.
While adding an entirely new target is one solution, another suggestion would be to have a specific CMake variable that could be used like CoreLibrariesDependencies
to override the logic for selecting default libraries. Perhaps a MSVC_CORE_LIBARIES
variable which if set overrides all the logic for CMAKE_C_STANDARD_LIBRARIES_INIT
.
A few test cases:
-
Build a DLL / EXE using only "onecore_apiset.lib". Due to some quirks of the Visual C/C++ CRT, this may also require
/NODEFAULTLIB:kernel32.lib
and/NODEFAULTLIB:onecore.lib
. When you use 'dumpbin /imports` on the resulting EXE or DLL should not have any direct references to KERNEL32.DLL and everything will reference API set DLLs. -
Build a DLL / EXE using only "onecore.lib". This will still have a KERNEL32.DLL reference, but will have most things bound to an API set instead.
-
Build a DLL / EXE using only "onecore_downlevel.lib".