Skip to content

WindowsToolchain and VCPkg don't work well together #59

@MarkSchofield

Description

@MarkSchofield

This issue is a conversation on using WindowsToolchain and VCPkg at the same time. At the minute there's a couple of problems:

  1. VCPkg support is added to a CMake build by setting CMAKE_TOOLCHAIN_FILE to [path to vcpkg]/scripts/buildsystems/vcpkg.cmake (as per the VCPkg 'Getting Started' documentation). CMAKE_TOOLCHAIN_FILE can 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.

  2. VCPkg adds a call to scripts/buildsystems/msbuild/applocal.ps1 to copy the DLL dependencies alongside the built binaries. But applocal.ps1 expects dumpbin, llvm-objdump or objdump to be found by PowerShell's Get-Command (here). If CMake/VCPkg is run from a Visual Studio Developer prompt, then dumpbin would be found, but since WindowsToolchain sets CMake properties to specify the compiler/utility paths, then the environment path doesn't contain dumpbin and applocal.ps1 fails:

    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.ps1 could 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.ps1 functionality by setting VCPKG_APPLOCAL_DEPS to OFF, 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions