Partial solution:
The Microsoft build tools include a batch file – vcvarsall.bat – to set up the environment for building – especially, defining the values of ${LIB} and ${LIBPATH} appropriate for the destination system. On my system, it’s located at:
“C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat”
There are three arguments that may be passed in:
CALL vcvarsall.bat [arch] [platform_type] [winsdk_version]
[arch] specifies the architecture of the build and execute systems – e.g., x64_arm64 sets up the environment to use x64 tools to create an arm64 executable. The “inheritEnvironments” variable in the CMakeSettings.json file, labeled “Toolset” in the GUI, handles this fine.
[platform_type] is the root of our problem. To link to the correct libraries for deploying to the HoloLens 2, [platform_type] must be uwp or store (synonymous). I have not found any way to manage this through CMake or the Visual Studio interface to CMake. If this argument is left unspecified, the default uses the usual desktop libraries, which work fine in desktop apps (including UWP), but not in HoloLens 2 apps.
What we’re doing now is using CMake to build the cache, then using a command-line prompt to:
CD into output directory (${CMAKE_BINARY_DIR})
CALL vcvarsall.bat x64_arm64 uwp
ninja clean
ninja all
I’ve written my own BAT file to manage this, along with some final file copying and
MakeAppx.exe ...
to create the deployable App package file. I invoke my BAT as a COMMAND in add_custom_target(_) from CMakeLists.txt (The “target” is the final package file created by MakeAppx.exe)
It mostly works, but seems a bit of a kludge to have to “manually” reset the environment and re-link all of the EXE and DLL files. Also, it seems not to be working 100% with regard to a prerequisite ExternalProject.
Still open to suggestions.
I think that there ought to be a way to manage the “uwp” or “store” specification along with x64_arm64 in the CMakeSettings.json – that would make the most sense. Maybe such a capability exists, but isn’t documented. ?
(Just to confuse things, CMakeSettings.json reverses the order of the build and execute systems; there, it’s specified as msvc_arm64_x64)