Arch Linux User Repository

Because of the recent issues with installing some packages, this package only provides the vcpkg executable from now on. Please follow the post-install instructions to set the VCPKG_ROOT environment variable and clone the vcpkg git repository. The default value for this variable is $HOME/.local/share/vcpkg.

Note: DO NOT set VCPKG_ROOT to any directory inside /usr or /opt!

Because of the recent issues with installing some packages, this package only provides the vcpkg executable from now on. Please follow the post-install instructions to set the VCPKG_ROOT environment variable and clone the vcpkg git repository. The default value for this variable is $HOME/.local/share/vcpkg.

Note: DO NOT set VCPKG_ROOT to any directory inside /usr or /opt!

/var/cache isn't supposed to be used for such things, according to FHS, even though Arch Packaging Guidelines do not forbid doing that.

The options you mentioned are experimental, so they aren't an alternative.

$HOME wont work in multiuser setup, however i'm currently use it.

Maybe place it in /var/lib?

I think the best way would be to keep it in /usr/lib and move buildtrees, packages, installed to /var/cache/vcpkg, but vcpkg currently doesn't have an options (Environment Variables) to specify this.

Yes there is --x-buildtrees-root=<path>, --x-install-root=<path>, --x-packages-root=<path> (https://learn.microsoft.com/en-us/vcpkg/commands/common-options#buildtrees-root), but there is no way to specify them globally in a way which all IDEs (VSCode) will understand them.

@hypo Moving vcpkg to /usr/lib was supposed to fix another build issue caused by vcpkg's root being /opt/vcpkg. Check out this issue: https://github.com/microsoft/vcpkg/issues/38522.

I think the only correct way to distribute this is to package only the vcpkg executable and place the root in the user's directory or something. That's how Fedora and Homebrew do it. They prefer using $HOME/.local/share/vcpkg, but you can put it anywhere by setting VCPKG_ROOT.

Looks like moving vcpkg to /usr/lib was a bad idea, because it breaks some package targets file generation.

For example, Catch2 can't be used with this error message:

CMake Error at /usr/lib/vcpkg/installed/x64-linux/share/catch2/Catch2Targets.cmake:103 (message):
  The imported target "Catch2::Catch2" references the file

     "/usr/lib/debug/lib/libCatch2d.a"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "/usr/lib/vcpkg/installed/x64-linux/share/catch2/Catch2Targets.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/vcpkg/installed/x64-linux/share/catch2/Catch2Config.cmake:44 (include)
  /usr/lib/vcpkg/scripts/buildsystems/vcpkg.cmake:859 (_find_package)
  CMakeLists.txt:56 (find_package)

The problem is in CMake, when packages installed in -https://github.com/Kitware/CMake/blob/ffa5d7d497e9e6e6a39bcdba328a8b8a712d9f04/Source/cmExportInstallFileGenerator.cxx#L229 - one of these prefixes it generates additional logic which cause error above - CMake tries to find libraries using wrong prefixes.

@petronny It builds sucessfully, but it doesn't work unless you set VCPKG_FORCE_SYSTEM_BINARIES=1 in your environment as well. I think I can fix this easily.

Exporting VCPKG_FORCE_SYSTEM_BINARIES=1 somewhere in the PKGBUILD works.

@petronny Thank you for notifying me about the issue. I'll test the possible patch on the Raspberry Pi shortly.

Build failed on aarch64:

 Environment variable VCPKG_FORCE_SYSTEM_BINARIES must be set on arm, s390x, ppc64le and riscv platforms.
==> ERROR: A failure occurred in build().
    Aborting...

https://github.com/arch4edu/cactus/actions/runs/6957553344/job/18930675352

Also there should be a note somewhere here on the aur page for that vcpkg group that I have to be in to use vcpkg without sudo because otherwise people will just use it with sudo which is not advised.