Suggestion: Remove X_VCPKG_APPLOCAL_DEPS_INSTALL and it's implementation

[MHebes]

The current behavior of X_VCPKG_APPLOCAL_DEPS_INSTALL overwrites the built-in install(TARGETS ...) command to do the following:

1. Run a PowerShell script that uses dumpbin, llvm-objdump, or objdump to list a target's runtime dependency names (e.g., libcrypto-3-x64.dll, libssl-3-64.dll, libpng16.dll, etc.).
2. Search for those names in some directories (notably, vcpkg_installed, which is the whole point).
3. Copy the files it finds to <install root>/bin or the folder that the user provided in install(... [RUNTIME] DESTINATION ...).

This is ostensibly a useful feature. However, I believe the vcpkg project would be better off leaving it out because it directly competes with CMake's built-in support for installing runtime dependencies, install(RUNTIME_DEPENDENCY_SET ...).

For one, there are a number of practical issues with reimplementing this behavior:

• General implementation details of finding runtime dependencies are difficult to get working well on all platforms: X_VCPKG_APPLOCAL_DEPS_INSTALL requires dumpbin to be on PATH for windows #43066
• Maintenance burden when arguments to install get updated: X_VCPKG_APPLOCAL_DEPS_INSTALL fails with install(... FILE_SET ...) #43243

I think it is way easier and works better with the ecosystem to instead just provide documentation on how to install vcpkg-provided packages using built-in CMake features:

install(
  TARGETS MyTarget
  RUNTIME_DEPENDENCY_SET MyTargetDeps
)

install(
  RUNTIME_DEPENDENCY_SET MyTargetDeps
  DIRECTORIES
    "${_VCPKG_INSTALLED_DIR}/${VCPKG_TARGET_TRIPLET}/$<$<CONFIG:Debug>:debug/>bin"
)

This is not perfect—there are plenty of weird workarounds necessary with this in practice. For instance, I need to manually exclude API sets and some random Windows DLLs that aren't actually DLLs:

    PRE_EXCLUDE_REGEXES
      "^(api|ext)-ms-.+$" # excludes Windows API sets
      "wpaxholder" # not sure why this is included!
      "azureattestmanager" # unknown why these Azure DLLs are linked but they aren't needed!
      "azureattestnormal"
    POST_EXCLUDE_REGEXES
      ".*system32.*" # C:/Windows/System32 means system libraries, which includes too many. Use include(InstallRequiredSystemLibraries) or a vcredist package instead.

In other projects, I have to manually include or exclude DLLs that are dynamically loaded, are the wrong version, etc.

However, these workarounds also will be needed in the vcpkg install(...) implementation if it becomes non-experimental. They would either have to be hardcoded in the applocal.ps1 script (creating another maintenance burden when things break) or exposed to the user somehow.

Basically, automatically finding dependency files for large projects gets very messy. install(RUNTIME_DEPENDENCY_SET ...) lets the user work around that messiness, and vcpkg provides the easiest part of that because it's already consolidated the DLLs in vcpkg_installed/bin.

I have a feeling that both X_VCPKG_APPLOCAL_DEPS_INSTALL and install(RUNTIME_DEPENDENCY_SET ...) are quite niche features, but I wanted to share my thoughts on this. What do you think?

---

P.S. add_executable and add_library do similar things if VCPKG_APPLOCAL_DEPS=ON, but they copy DLLs next to the target file in the build tree instead of the install tree. I understand the usefulness here, since there is no similar built-in CMake way to copy runtime dependencies to the build tree. These also do not have the same practical issues with reparsing arguments. However, I would still encourage the toolchain file to use file(GET_RUNTIME_DEPENDENCIES ...) to find dependencies instead of a custom PowerShell script to reduce duplicate implementation and differences in behavior between build time and install time.

[Osyotr]

It can't be removed bacuse install(RUNTIME_DEPENDENCY_SET) is a CMake 3.21 feature but vcpkg supports CMake 3.16.3.

I think it is way easier and works better with the ecosystem to instead just provide documentation on how to install vcpkg-provided packages using built-in CMake features

Yes!

[MHebes]

That’s a good point! I’m unable to find a source for your 3.16.3 minimum, but the things I’ve found say the required version might be even lower.

One could argue that vcpkg doesn’t necessarily need to get in the business of shipping existing features just because they’re missing from older CMake versions—but I get your point.

I believe the docs could show the example for 3.21. Then, for pre-3.21, installing vcpkg-sourced DLLs is pretty trivial even without install(RUNTIME_DEPENDENCY_SET ...). If you have 3.16 you can write equivalent functionality with file(GET_RUNTIME_DEPENDENCY_SET ...) and a few more install(PROGRAMS ...) lines, and if you’re on an older version you can manually list dependencies, which will all be in the vcpkg_install/bin folder for you.

[Osyotr]

https://learn.microsoft.com/en-us/vcpkg/concepts/supported-hosts#linux-1