-
Notifications
You must be signed in to change notification settings - Fork 26
Description
This issue is a conversation on using WindowsToolchain and VCPkg at the same time. At the minute there's a couple of problems:
-
VCPkg support is added to a CMake build by setting
CMAKE_TOOLCHAIN_FILEto[path to vcpkg]/scripts/buildsystems/vcpkg.cmake(as per the VCPkg 'Getting Started' documentation).CMAKE_TOOLCHAIN_FILEcan only specify a single file and is treated specially by CMake - as discussed in the CMake code-injection documentation. If the VCPkg support is specified as the toolchain, then WindowsToolchain can't be specified as the toolchain.The cmake-toolchains(7) documentation explains the role of the toolchain file is to provide information on compiler/utility paths, and the VCPkg support doesn't seem to fulfil that role - What is the point of using vcpkg.cmake as a toolchain? microsoft/vcpkg#22675 is a conversation that covers this. As an alternative, CMake 3.24 added support for CMAKE_PROJECT_TOP_LEVEL_INCLUDES which "provides an injection point for things like configuring package managers, adding logic the user shares between projects (e.g. defining their own custom build types), and so on". VCPkg could be enabled through
CMAKE_PROJECT_TOP_LEVEL_INCLUDES, and CMAKE_PROJECT_TOP_LEVEL_INCLUDES microsoft/vcpkg#26681 discusses that. -
VCPkg adds a call to
scripts/buildsystems/msbuild/applocal.ps1to copy the DLL dependencies alongside the built binaries. Butapplocal.ps1expectsdumpbin,llvm-objdumporobjdumpto be found by PowerShell'sGet-Command(here). If CMake/VCPkg is run from a Visual Studio Developer prompt, thendumpbinwould be found, but since WindowsToolchain sets CMake properties to specify the compiler/utility paths, then the environment path doesn't containdumpbinandapplocal.ps1fails:resolve: VCPkg\scripts\buildsystems\msbuild\applocal.ps1:162 Line | 162 | resolve($targetBinary) | ~~~~~~~~~~~~~~~~~~~~~~ | Neither dumpbin, llvm-objdump nor objdump could be found. Can not take care of dll dependencies.
Using the environment path to find utilities isn't very 'toolchain-y'. If
applocal.ps1could be told the command to use, or the path to search, then it could remove its dependency on the environment.It is possible to opt-out of VCPkg's
applocal.ps1functionality by settingVCPKG_APPLOCAL_DEPStoOFF, but if a port/triplet produces a DLL dependency it would need to be copied through some other means, but this would unblock header-only and static-library consumption.