take dependencies from locally cloned repo

[Andriy Fedechko (andriy-fedechko-imprivata)]

Hello,
Not sure how to better describe the problem I'd like to solve, so I'll start from describing an environment I have and then will try to describe a problem I'd like to address.

I have a few repos, where each provides some functionality (assume that each repo provides some standalone library). For simplicity, I have repo A and repo B. And these repos has next relation: Repo A uses library provided by repo B.
The way how A's dependencies are resolved right now is: I have a custom registry repository, that holds a repo's B port file. It has vcpkg.json file with the dependencies for repo B and it has portfile.cmake that instructs where from repo B can be taken, how it can be built, etc.

Then my repo A has a vcpkg-configuration.json that "points" to that custom registry, and the vcpkg.json that has a lists dependencies of A.

Now the problem.
Imagine that I have to do some changes within repo B and I'd like to test these changes within repo A. For example, let's imagine that repo B provides a library for logging, and repo A is the application that uses that library. Now I have added new functionality into logging library and I'd like to test how it works with the application provided by repo A. The way I can do that is next:

1. do changes within repo B
2. commit changes in B
3. go to custom registry repo and update B's portfile to point to new commit, basically add new version of B
4. commit these changes as well
5. now go to my repo A, update the vcpkg-configuration.json with new baseline, so that it takes new registry, where new data about B's is provided
6. now I can build A and it will have changes recently done in B.

So... I'm looking for a way to simplify that process a bit. For dev-testing.
Given that I have repo A and repo B on my system, locally, both are cloned to some local folder... is there a way to skip 2-5 from the steps above, and do something like this:

1. do changes in repo B
2. do some changes in repo A's vcpkg-configuration.json file, or somewhere else, so that it takes repo B not from custom registry but from /some/folder/within/my_os
3. test changes.

I've tried to use builtin registry within A's vcpkg-configuration.json and specifying the VCPKG_OVERLAY_PORTS to the /some/folder/within/my_os but it complains that local repo B desn't have portfile.cmake file, which is logical as this should not be a part of the B's repo.
But all it can give me is that I can copy B's vcpkg.json and portfile.cmake into folder into which VCPKG_OVERLAY_PORTS points to, and l can skip updating custom registry step. But still will be getting changes from B's repo. And I'd like to skip that step as well.

[Jack·Boos·Yu (JackBoosY)]

The simply way is: directly extract repo B's package or just copy it instead of use vcpkg_from_github / vcpkg_download_distfile temporary before you updated the version.

[ProgramGamer (miss-programgamer)]

What does "directly extract repo B's package" mean, and how am I expected to then consume it from library A in this theoretical?

[Jack·Boos·Yu (JackBoosY)]

Use vcpkg_extract_source_archive‎ instead of vcpkg_from_github / vcpkg_download_distfile,
see: https://github.com/microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_extract_source_archive.cmake

[Mukunda Rao Katta (MukundaKatta)]

The clean way is an overlay port + filesystem registry pointing at your local checkout. In your A repo's vcpkg-configuration.json, add a filesystem registry with "path": "../path/to/portB-registry". The portfile under that registry uses vcpkg_from_git with a local file:// URL (or SOURCE_PATH directly) to pull from your B checkout. That way A's vcpkg consumes exactly the local B bits, versioning still works, and you don't have to edit ports in-tree.

[Aleksandr Kovalko (gistrec)]

Adding to Mukunda Rao Katta (@MukundaKatta): for local iteration you usually do not need a second filesystem registry. An overlay port is enough.

For example, in repo A you can create:

overlays/
  repo-b/
    vcpkg.json
    portfile.cmake

overlays/repo-b/vcpkg.json:

{
  "name": "repo-b",
  "version-string": "local",
  "dependencies": [
    {
      "name": "vcpkg-cmake",
      "host": true
    },
    {
      "name": "vcpkg-cmake-config",
      "host": true
    }
  ]
}

overlays/repo-b/portfile.cmake:

if(NOT DEFINED ENV{REPO_B_PATH})
    message(FATAL_ERROR "Please set REPO_B_PATH to your local repo-b checkout")
endif()

set(SOURCE_PATH "$ENV{REPO_B_PATH}")

vcpkg_cmake_configure(
    SOURCE_PATH "${SOURCE_PATH}"
)

vcpkg_cmake_install()

# Only needed if repo-b installs CMake package config files.
vcpkg_cmake_config_fixup()

Then reference the overlay in repo A's vcpkg-configuration.json, alongside your existing registry:

{
  "overlay-ports": [
    "./overlays"
  ],
  "registries": [
    // your existing registry config
  ]
}

Or pass it on the command line:

vcpkg install --overlay-ports=./overlays

Overlay ports take precedence over registry ports when resolving package names, so repo-b will be built from your local checkout while the rest of your dependencies still come from the configured registries.

When you are done testing the local changes, remove the overlay entry or unset REPO_B_PATH, and vcpkg will go back to resolving repo-b from your registry.