Support EWDK for building packages

[Starl1ght]

Describe the bug
Microsoft provides special driver building tools (portable WDK + MSVC build tools), called EWDK (https://learn.microsoft.com/en-us/Windows-hardware/drivers/download-the-wdk - here Enterprise WDK)

The problem is, that VCPKG cannot see it and unable to use it, forcing me to install separate set of build tools on a build machine specially for VCPKG.

Environment

• OS: Win10
• Compiler: EWDK 22H2

To Reproduce
Steps to reproduce the behavior:
Get a clear VM, download EWDK, start EWDK shell, download VCPKG, try to install any package via VCPKG.
Get an error that "No visual studio instance was found"

Expected behavior
I expect VCPKG to find and use EWDK for building packages, or, at least, a way to manually tell VCPKG where to find EWDK

Failure logs
Error: in triplet x64-windows-static-md: Unable to find a valid Visual Studio instance
Could not locate a complete Visual Studio instance

Additional context
I think it's should be possible to trick VCPKG somehow that EWDK is actually a MSVC installed, by creating some symlinks in C:\program files, but I'm too lazy to do it.

[thxkiwi]

This is something I'd be happy to work on as I need this functionality.

I've tried a few times since late 2021. I've most recently tried using EWDK 22621 that ships with vsbuildtools 17.1.5 and vcpkg tag 2023.06.20.

I can get an instance of the EWDK that correctly builds msbuild projects for 10.0.22621.0 and toolset v143.

I understand that vcpkg makes use of vs_where.exe but the EWDK does not leave behind any remnants of the installer.

I've tried using VCKPG_VISUAL_STUDIO_PATH=<EWDK>\...\Microsoft Visual Studio\2022\Buildtools with the following results

C:\host\docker\EWDK-22621>\vcpkg\vcpkg.exe install zlib --triplet x64-windows
Computing installation plan...
The following packages will be built and installed:
    zlib:x64-windows -> 1.2.13
error: in triplet x64-windows: Unable to find a valid Visual Studio instance
    at "C:\host\docker\EWDK-22621\Program Files\Microsoft Visual Studio\2022\BuildTools"
Could not locate a complete Visual Studio instance

It seems like vcpkg (tag 2022.06.15) doesn't use VS170COMNTOOLS environment variable. I've tried setting VS160COMNTOOLS=%VS170COMNTOOLS% based on other feedback here (#22068 (comment)). This gets a little further but still ultimately fails...

C:\host\docker\EWDK-22621>\vcpkg\vcpkg.exe install zlib --triplet x64-windows
Computing installation plan...
The following packages will be built and installed:
    zlib:x64-windows -> 1.2.13
Detecting compiler hash for triplet x64-windows...
Restored 0 package(s) from C:\Users\ContainerAdministrator\AppData\Local\vcpkg\archives in 99.8 us. Use --debug to see more details.
Installing 1/1 zlib:x64-windows...
Building zlib:x64-windows...
-- Using cached madler-zlib-v1.2.13.tar.gz.
-- Cleaning sources at C:/vcpkg/buildtrees/zlib/src/v1.2.13-f30d2a168d.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/vcpkg/downloads/madler-zlib-v1.2.13.tar.gz
-- Applying patch 0001-Prevent-invalid-inclusions-when-HAVE_-is-set-to-0.patch
-- Applying patch 0002-skip-building-examples.patch
-- Applying patch 0003-build-static-or-shared-not-both.patch
-- Applying patch 0004-android-and-mingw-fixes.patch
-- Using source at C:/vcpkg/buildtrees/zlib/src/v1.2.13-f30d2a168d.clean
-- Configuring x64-windows
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:112 (message):
    Command failed: C:/vcpkg/downloads/tools/ninja/1.10.2-windows/ninja.exe -v
    Working Directory: C:/vcpkg/buildtrees/zlib/x64-windows-rel/vcpkg-parallel-configure
    Error code: 1
    See logs for more information:
      C:\vcpkg\buildtrees\zlib\config-x64-windows-dbg-CMakeCache.txt.log
      C:\vcpkg\buildtrees\zlib\config-x64-windows-rel-CMakeCache.txt.log
      C:\vcpkg\buildtrees\zlib\config-x64-windows-out.log

Call Stack (most recent call first):
  installed/x64-windows/share/vcpkg-cmake/vcpkg_cmake_configure.cmake:252 (vcpkg_execute_required_process)
  ports/zlib/portfile.cmake:18 (vcpkg_cmake_configure)
  scripts/ports.cmake:147 (include)


error: building zlib:x64-windows failed with: BUILD_FAILED
Elapsed time to handle zlib:x64-windows: 1.6 s
Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
    https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+zlib
You can submit a new issue at:
    https://github.com/microsoft/vcpkg/issues/new?title=[zlib]+Build+error&body=Copy+issue+body+from+C%3A%2Fvcpkg%2Finstalled%2Fvcpkg%2Fissue_body.md

where the output from the config logs

C:\host\docker\EWDK-22621>more C:\vcpkg\buildtrees\zlib\config-x64-windows-out.log
[1/2] "C:/vcpkg/downloads/tools/cmake-3.25.1-windows/cmake-3.25.1-windows-i386/bin/cmake.exe" -E chdir "../../x64-windows-dbg" "C:/vcpkg/downloads/tools/cmake-3.25.1-windows/cmake-3.25.1-windows-i386/bin/cmake.exe" "C:/vcpkg/buildtrees/zlib/src/v1.2.13-f30d2a168d.clean" "-G" "Ninja" "-DCMAKE_BUILD_TYPE=Debug" "-DCMAKE_INSTALL_PREFIX=C:/vcpkg/packages/zlib_x64-windows/debug" "-DFETCHCONTENT_FULLY_DISCONNECTED=ON" "-DSKIP_INSTALL_FILES=ON" "-DCMAKE_MAKE_PROGRAM=C:/vcpkg/downloads/tools/ninja/1.10.2-windows/ninja.exe" "-DBUILD_SHARED_LIBS=ON" "-DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=C:/vcpkg/scripts/toolchains/windows.cmake" "-DVCPKG_TARGET_TRIPLET=x64-windows" "-DVCPKG_SET_CHARSET_FLAG=ON" "-DVCPKG_PLATFORM_TOOLSET=v143" "-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON" "-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON" "-DCMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY=ON" "-DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP=TRUE" "-DCMAKE_VERBOSE_MAKEFILE=ON" "-DVCPKG_APPLOCAL_DEPS=OFF" "-DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake" "-DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=ON" "-DVCPKG_CXX_FLAGS=" "-DVCPKG_CXX_FLAGS_RELEASE=" "-DVCPKG_CXX_FLAGS_DEBUG=" "-DVCPKG_C_FLAGS=" "-DVCPKG_C_FLAGS_RELEASE=" "-DVCPKG_C_FLAGS_DEBUG=" "-DVCPKG_CRT_LINKAGE=dynamic" "-DVCPKG_LINKER_FLAGS=" "-DVCPKG_LINKER_FLAGS_RELEASE=" "-DVCPKG_LINKER_FLAGS_DEBUG=" "-DVCPKG_TARGET_ARCHITECTURE=x64" "-DCMAKE_INSTALL_LIBDIR:STRING=lib" "-DCMAKE_INSTALL_BINDIR:STRING=bin" "-D_VCPKG_ROOT_DIR=C:/vcpkg" "-D_VCPKG_INSTALLED_DIR=C:/vcpkg/installed" "-DVCPKG_MANIFEST_INSTALL=OFF" "-DSKIP_INSTALL_HEADERS=ON"
FAILED: ../../x64-windows-dbg/CMakeCache.txt
"C:/vcpkg/downloads/tools/cmake-3.25.1-windows/cmake-3.25.1-windows-i386/bin/cmake.exe" -E chdir "../../x64-windows-dbg" "C:/vcpkg/downloads/tools/cmake-3.25.1-windows/cmake-3.25.1-windows-i386/bin/cmake.exe" "C:/vcpkg/buildtrees/zlib/src/v1.2.13-f30d2a168d.clean" "-G" "Ninja" "-DCMAKE_BUILD_TYPE=Debug" "-DCMAKE_INSTALL_PREFIX=C:/vcpkg/packages/zlib_x64-windows/debug" "-DFETCHCONTENT_FULLY_DISCONNECTED=ON" "-DSKIP_INSTALL_FILES=ON" "-DCMAKE_MAKE_PROGRAM=C:/vcpkg/downloads/tools/ninja/1.10.2-windows/ninja.exe" "-DBUILD_SHARED_LIBS=ON" "-DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=C:/vcpkg/scripts/toolchains/windows.cmake" "-DVCPKG_TARGET_TRIPLET=x64-windows" "-DVCPKG_SET_CHARSET_FLAG=ON" "-DVCPKG_PLATFORM_TOOLSET=v143" "-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON" "-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON" "-DCMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY=ON" "-DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP=TRUE" "-DCMAKE_VERBOSE_MAKEFILE=ON" "-DVCPKG_APPLOCAL_DEPS=OFF" "-DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake" "-DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=ON" "-DVCPKG_CXX_FLAGS=" "-DVCPKG_CXX_FLAGS_RELEASE=" "-DVCPKG_CXX_FLAGS_DEBUG=" "-DVCPKG_C_FLAGS=" "-DVCPKG_C_FLAGS_RELEASE=" "-DVCPKG_C_FLAGS_DEBUG=" "-DVCPKG_CRT_LINKAGE=dynamic" "-DVCPKG_LINKER_FLAGS=" "-DVCPKG_LINKER_FLAGS_RELEASE=" "-DVCPKG_LINKER_FLAGS_DEBUG=" "-DVCPKG_TARGET_ARCHITECTURE=x64" "-DCMAKE_INSTALL_LIBDIR:STRING=lib" "-DCMAKE_INSTALL_BINDIR:STRING=bin" "-D_VCPKG_ROOT_DIR=C:/vcpkg" "-D_VCPKG_INSTALLED_DIR=C:/vcpkg/installed" "-DVCPKG_MANIFEST_INSTALL=OFF" "-DSKIP_INSTALL_HEADERS=ON"
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- The C compiler identification is MSVC 19.31.31107.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: C:/host/docker/EWDK-22621/Program Files/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.31.31103/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/host/docker/EWDK-22621/Program Files/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.31.31103/bin/Hostx64/x64/cl.exe - broken
CMake Error at C:/vcpkg/downloads/tools/cmake-3.25.1-windows/cmake-3.25.1-windows-i386/share/cmake-3.25/Modules/CMakeTestCCompiler.cmake:70 (message):
  The C compiler

    "C:/host/docker/EWDK-22621/Program Files/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.31.31103/bin/Hostx64/x64/cl.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: C:/vcpkg/buildtrees/zlib/x64-windows-dbg/CMakeFiles/CMakeScratch/TryCompile-d06g5a

    Run Build Command(s):C:/vcpkg/downloads/tools/ninja/1.10.2-windows/ninja.exe cmTC_10ec4 && [1/2] Building C object CMakeFiles\cmTC_10ec4.dir\testCCompiler.c.obj
    [2/2] Linking C executable cmTC_10ec4.exe
    FAILED: cmTC_10ec4.exe
    cmd.exe /C "cd . && C:\vcpkg\downloads\tools\cmake-3.25.1-windows\cmake-3.25.1-windows-i386\bin\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_10ec4.dir --rc=rc --mt=CMAKE_MT-NOTFOUND --manifests  -- C:\host\docker\EWDK-2~1\PROGRA~1\MICROS~3\2022\BUILDT~1\VC\Tools\MSVC\1431~1.311\bin\Hostx64\x64\link.exe /nologo CMakeFiles\cmTC_10ec4.dir\testCCompiler.c.obj  /out:cmTC_10ec4.exe /implib:cmTC_10ec4.lib /pdb:cmTC_10ec4.pdb /version:0.0 /machine:x64  /debug /INCREMENTAL /subsystem:console  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
    RC Pass 1: command "rc /fo CMakeFiles\cmTC_10ec4.dir/manifest.res CMakeFiles\cmTC_10ec4.dir/manifest.rc" failed (exit code 0) with the following output:
    The system cannot find the file specified
    ninja: build stopped: subcommand failed.





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:4 (project)


-- Configuring incomplete, errors occurred!
See also "C:/vcpkg/buildtrees/zlib/x64-windows-dbg/CMakeFiles/CMakeOutput.log".
See also "C:/vcpkg/buildtrees/zlib/x64-windows-dbg/CMakeFiles/CMakeError.log".

CmakeError.log seems to just provide the similar output as above

C:\host\docker\EWDK-22621>more "C:/vcpkg/buildtrees/zlib/x64-windows-dbg/CMakeFiles/CMakeError.log"
Detecting C compiler ABI info failed to compile with the following output:
Change Dir: C:/vcpkg/buildtrees/zlib/x64-windows-dbg/CMakeFiles/CMakeScratch/TryCompile-fphwsf

Run Build Command(s):C:/vcpkg/downloads/tools/ninja/1.10.2-windows/ninja.exe cmTC_6bf54 && [1/2] Building C object CMakeFiles\cmTC_6bf54.dir\CMakeCCompilerABI.c.obj
[2/2] Linking C executable cmTC_6bf54.exe
FAILED: cmTC_6bf54.exe
cmd.exe /C "cd . && C:\vcpkg\downloads\tools\cmake-3.25.1-windows\cmake-3.25.1-windows-i386\bin\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_6bf54.dir --rc=rc --mt=CMAKE_MT-NOTFOUND --manifests  -- C:\host\docker\EWDK-2~1\PROGRA~1\MICROS~3\2022\BUILDT~1\VC\Tools\MSVC\1431~1.311\bin\Hostx64\x64\link.exe /nologo CMakeFiles\cmTC_6bf54.dir\CMakeCCompilerABI.c.obj  /out:cmTC_6bf54.exe /implib:cmTC_6bf54.lib /pdb:cmTC_6bf54.pdb /version:0.0 /machine:x64  /debug /INCREMENTAL /subsystem:console  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
RC Pass 1: command "rc /fo CMakeFiles\cmTC_6bf54.dir/manifest.res CMakeFiles\cmTC_6bf54.dir/manifest.rc" failed (exit code 0) with the following output:
The system cannot find the file specified
ninja: build stopped: subcommand failed.




Determining if the C compiler works failed with the following output:
Change Dir: C:/vcpkg/buildtrees/zlib/x64-windows-dbg/CMakeFiles/CMakeScratch/TryCompile-d06g5a

Run Build Command(s):C:/vcpkg/downloads/tools/ninja/1.10.2-windows/ninja.exe cmTC_10ec4 && [1/2] Building C object CMakeFiles\cmTC_10ec4.dir\testCCompiler.c.obj
[2/2] Linking C executable cmTC_10ec4.exe
FAILED: cmTC_10ec4.exe
cmd.exe /C "cd . && C:\vcpkg\downloads\tools\cmake-3.25.1-windows\cmake-3.25.1-windows-i386\bin\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_10ec4.dir --rc=rc --mt=CMAKE_MT-NOTFOUND --manifests  -- C:\host\docker\EWDK-2~1\PROGRA~1\MICROS~3\2022\BUILDT~1\VC\Tools\MSVC\1431~1.311\bin\Hostx64\x64\link.exe /nologo CMakeFiles\cmTC_10ec4.dir\testCCompiler.c.obj  /out:cmTC_10ec4.exe /implib:cmTC_10ec4.lib /pdb:cmTC_10ec4.pdb /version:0.0 /machine:x64  /debug /INCREMENTAL /subsystem:console  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
RC Pass 1: command "rc /fo CMakeFiles\cmTC_10ec4.dir/manifest.res CMakeFiles\cmTC_10ec4.dir/manifest.rc" failed (exit code 0) with the following output:
The system cannot find the file specified
ninja: build stopped: subcommand failed.

It seems like at this point there is something required to get CMake to find the EWDK buildtools instance, if anyone can help with CMake, I'd appreciate it.

[thxkiwi]

Ok, after setting %LIB% and %INCLUDE% I was able to get zlib (using the vcpkg downloaded source) to build using cmake+ninja (also downloaded via vcpkg) on the command line via

cd vcpkg\buildtrees\zlib\src\<vcpkg unarchived zlib src>
cmake -S . -B build -G Ninja -DCMAKE_MAKE_PROGRAM:FILEPATH=\vcpkg\downloads\tools\ninja\...\ninja.exe
cmake --build build 

It seems the original issue is related to how vcpkg invokes cmake.

[thxkiwi]

Furthermore, based on what fails

-- Configuring x64-windows
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:112 (message):
    Command failed: C:/vcpkg/downloads/tools/ninja/1.10.2-windows/ninja.exe -v
    Working Directory: C:/vcpkg/buildtrees/zlib/x64-windows-rel/vcpkg-parallel-configure
    Error code: 1
    See logs for more information:
      C:\vcpkg\buildtrees\zlib\config-x64-windows-dbg-CMakeCache.txt.log
      C:\vcpkg\buildtrees\zlib\config-x64-windows-rel-CMakeCache.txt.log
      C:\vcpkg\buildtrees\zlib\config-x64-windows-out.log

after setting LIB and INCLUDE env vars in the current shell and CD'ing to the working directory, executing the command (ninja -v) succeeds.

What could vcpkg_execute_required_process be doing differently why the command succeeds in the shell but fails when executed via vcpkg_execute_required_process?

[thxkiwi]

Confirmed, via a shim "ninja.exe" that dumps the variables of the environment in which it executes, that when ninja is executed through vcpkg -> cmake -> ninja, it is not receiving the environment from the shell in which vcpkg was executed.

I've tried using setx INCLUDE ... /M and setx LIB ... /M but still they're not inherited by the vcpkg -> cmake -> ninja invocation.

[thxkiwi]

Tried using VCPKG_KEEP_ENV_VARS=INCLUDE;LIB;VS16COMNTOOLS (these are the env vars I had to set within the EWDK environment to get zlib to build) but vcpkg_cmake_configure from the zlib portfile.cmake still fails. Digging further with vcpkg env contrasts many differences between the vcpkg environment and the executing shell environment.

Within the first couple of diffs are env vars within the vcpkg environment that are not even set within the executing shell environment. If I'm reading the data correctly it appears that vcpkg

1. sets __DOTNET_ADD_64BIT when it was never set in the executing environment.
2. sets __VSCMD_PREINIT_INCLUDE when it was never set in the executing environment.
3. overrides __DOTNET_PREFERRED_BITNESS from how it was set in the executing environment.

There are a lot more than just these. Why does vcpkg insist on controlling the environment incorrectly? I can understand wanting a consistent build environment but is vcpkg getting it wrong?

The following diffs were generated using an equivalent to

set | sort > working.env
vcpkg env
set | sort > notworking.env
diff working.env notworking.env

2,3c2,5
< __DOTNET_PREFERRED_BITNESS=32
< __VSCMD_PREINIT_PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\ContainerAdministrator\AppData\Local\Microsoft\WindowsApps;C:\Program Files\Git\bin;
---
> __DOTNET_ADD_64BIT=1
> __DOTNET_PREFERRED_BITNESS=64
> __VSCMD_PREINIT_INCLUDE=C:\host\docker\EWDK-22621\Program Files\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.31.31103\ATLMFC\include;C:\host\docker\EWDK-22621\Program Files\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.31.31103\include;C:\host\docker\EWDK-22621\Program Files\Windows Kits\10\Include\10.0.22621.0\ucrt;C:\host\docker\EWDK-22621\Program Files\Windows Kits\10\Include\10.0.22621.0\um;C:\host\docker\EWDK-22621\Program Files\Windows Kits\10\Include\10.0.22621.0\shared;C:\host\docker\EWDK-22621\Program Files\Windows Kits\10\Include\10.0.22621.0\winrt;C:\host\docker\EWDK-22621\Program Files\Windows Kits\10\Include\10.0.22621.0\cppwinrt;C:\host\docker\EWDK-22621\Program Files\Windows Kits\10\Include\10.0.22621.0\ucrt;C:\host\docker\EWDK-22621\Program Files\Windows Kits\10\Include\10.0.22621.0\um;C:\host\docker\EWDK-22621\Program Files\Windows Kits\10\Include\10.0.22621.0\shared;C:\host\docker\EWDK-22621\Program Files\Windows Kits\10\Include\10.0.22621.0\winrt;C:\host\docker\EWDK-22621\Program Files\Windows Kits\10\Include\10.0.22621.0\cppwinrt
> __VSCMD_PREINIT_PATH=C:\Windows\system32;C:\Windows;C:\Windows\system32\Wbem;C:\Windows\system32\WindowsPowerShell\v1.0\
6,10c8
< BuildBranch=ni_release_svc_prod3
< BuildLab=ni_release_svc_prod3.22621.1778
< BuildLabSetupFilesRoot=C:\host\docker\EWDK-22621\Program Files
< BuildLabSetupRoot=C:\host\docker\EWDK-22621
< CommandPromptType=Native
---
> CommandPromptType=Cross

working.env.txt
notworking.env.txt

[thxkiwi]

Think I've finally got to the bottom of this. The issue is created by a combination of vcpkg's clean environment, and the EWDK not setting env vars for the Windows SDK (my guess here is because VS winsdk.bat uses the registry to find the SDK installation folders, and the EWDK doesn't modify the registry).

In my case I'm actually trying to run all of this inside a docker container for CI/CD so in this case the good news is that adding the correct entries to the registry for the container to allow winsdk.bat to find the Windows SDK of EWDK, an extra invocation of VsDevCmd.bat, and setting up a couple of env vars for vcpkg, provides workaround

The registry values needed for the EWDK 10.0.22621.0 are as follows.

New-Item -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v10.0" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v10.0" -Name "InstallationFolder" -Value "C:\host\docker\ewdk-22621\Program Files\Windows Kits\10\" -Type String
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v10.0" -Name "ProductName" -Value "Microsoft Windows SDK for Windows 10.0.22621" -Type String
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v10.0" -Name "ProductVersion" -Value "10.0.22621" -Type String

New-Item -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows Kits\Installed Roots" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows Kits\Installed Roots" -Name "KitsRoot10" -Value "C:\host\docker\ewdk-22621\Program Files\Windows Kits\10\" -Type String

1. LaunchBuildEnv.cmd amd64 ; calls VsDevCmd.bat with -winsdk=none, so...
2. \Program Files\Microsoft Visual Studio\2022\BuildTools\Common7\Tools\VsDevCmd.bat -arch=amd64 -host_arch=amd64 -winsdk=10.0.22621.0 -vcvars_ver=14.31.31103

sets up a fully working EWDK inside the container with INCLUDE and LIB set correctly for the Windows SDK 10.0.22621.0 from the EWDK. This could easily be merged to a single script that does what LaunchBuildEnv.cmd does but instead calls VsDevCmd.bat with -winsdk=10.0.22621.0 instead of -winsdk=none.

For vcpkg,

set VS160COMNTOOLS=%VS170COMNTOOLS% 

(this is an odd one because vcpkg-tool has been updated for VS toolchain v143 from VS 17, but not for the env var VS170COMNTOOLS from VS 17)

set VCPKG_KEEP_ENV_VARS=LIB;INCLUDE;VS160COMNTOOLS

to ensure that the env vars for the Windows SDK are preserved when vcpkg creates the build environment. Likewise since the VS toolchain vcvarsall.bat in VS 17+ creates VS170COMNTOOLS env var and not VS160COMNTOOLS, preserve our setting of VS160COMNTOOLS in the vcpkg build environment.

[thxkiwi]

According to https://discourse.cmake.org/t/cmake-configure-project-with-ewdk-toolchain/8417 simply using ninja as the CMake generator should work, yet vcpkg_cmake_configure is failing.

[StarGate-One]

If this helps the latest vswhere.exe can be downloaded at microsoft/vswhere - it is normally found in directory C:\Program Files (x86)\Microsoft Visual Studio\Installer.

[thxkiwi]

Thank you. Good to know.

[thxkiwi]

@StarGate-One I did get everything working in a container without needing a separate build of vswhere. I'll try adding vswhere to my findings because I'm hoping it will remove the need to set VS160COMNTOOLS=%VS170COMNTOOLS% and VCPKG_KEEP_ENV_VARS=...;VS160COMNTOOLS.