How do I use nested vcpkg manifests in submodules/sub-projects? #18122

You can use features for this: https://github.com/microsoft/vcpkg/blob/master/docs/users/manifests.md#vcpkg_manifest_features

@derekcyruschow-catapult it is quite specific to our workflow, but you might get some inspiration https://github.com/inviwo/inviwo/blob/71f4dd278595367a84d1c1cb8317fe9113becb4d/cmake/vcpkg-manifest-generation-toolchain.cmake

Greetings from 2026! Any news on official multi-json support? This current limitation is unfortunate if you want to distribute source for a middleware library that uses vcpkg via submodule. It's not a realistic expectation for a user of the middleware library to merge the json if they too are using vcpkg. They should just be able to add_subdirectory and have it "just work".

They should just be able to add_subdirectory and have it "just work".

IMO this is difficult in a robust "just work" quality. add_directory() typically takes place after toolchain setup, i.e. after project(). Sometimes it is subject to if() conditions.

But vcpkg dependency resolution and installation must be done once and early. With vcpkg manifest mode it takes place during the top-level project(). It can consider features and overlay ports if this information is present at that time. But it doesn't know which subdirectories are visited later.

The robust way which is available now is overlay ports and find_package().

Disclaimer: Community feedback.

The robust way which is available now is overlay ports and find_package().

Kai Pastor (@dg0yt) sorry I'm not sure I follow, do you have an example of this you can share please?

This probably isn't what Kai Pastor (@dg0yt) was referring to, but what I've found for my own internal projects I can do the following. Maybe it will spawn some ideas for you. In the end it's all just workarounds and I think there are a lot of gotcha's that prevent a robust solution to this being built into vcpkg (because of the version challenges, what baseline is used, etc).

In the subproject, create a "dummy" overlay-port that is just used to list out that subproject's dependencies. So..

# portfile.cmake
set(VCPKG_POLICY_EMPTY_PACKAGE enabled)

# vcpkg.json (in the overlay)
{
  "name": "my-subproject-deps",
  "version": "1.0.0",
  "description": "Meta-port that centralizes manifest dependencies",
  "dependencies": [ ... ]
}

my-subproject's root vcpkg.json can just point to the overlay port and list that as it's only dependency. For my purposes I have vcpkg as a submodule in that subproject and can clone it and work in just that subproject if needed.

# my-subproject's root vcpkg.json
{
  "$schema": "https://raw.githubusercontent.com/microsoft/vcpkg-tool/main/docs/vcpkg.schema.json",
  "name": "my-subproject",
  "version": "1.0.0",
  "dependencies": ["my-subproject-deps"],
  "vcpkg-configuration": {
    "overlay-ports": [
      "./vcpkg-overlay-ports/my-subproject-dep",
    ],
  },
  "builtin-baseline": "..."
}

Then in the parent project, also with vcpkg as a submodule:

1. Add my-subproject as a git submodule
2. Add (to root vcpkg.json) the subproject's overlay port and my-subproject-deps to the dependency array.
3. Configure and build.

# project root vcpkg.json
{
  "$schema": "https://raw.githubusercontent.com/microsoft/vcpkg-tool/main/docs/vcpkg.schema.json",
  "name": "project",
  "version": "1.0.0",
  "dependencies": [
    "my-subproject-deps",
    ... all of my other dependencies ...
  ],
  "vcpkg-configuration": {
    "overlay-ports": [
      "./submodules/my-subproject/vcpkg-overlay-ports/my-subproject-deps",
    ],
}

Hope that helps or spawns some more ideas. Other options could be better, but this satisfied my desire to be able to actively develop in the root project and subproject in parallel without having to jump through hoops every time I want to add another vcpkg dependency to either.

Was just musing over how to solve this as well, we can hijack the fact that vcpkg ignores keys with $ in their name, then with this bash script and a top level "$include": "" value in the vcpkg manifest, this script will install each dependency:

#!/bin/bash

MANIFEST=$1

function pop() {
  popd > /dev/null
}
trap pop EXIT

if [[ ! -f $MANIFEST ]]; then
  echo "usage: ports.sh <manifest.json>"
  exit 1
fi

MANIFEST=$(realpath "$MANIFEST")

readarray -t DEPS < <(cat $MANIFEST | jq -r ".dependencies" | tr -d '[],:{}" ' | sed '/^$/d')

pushd /tmp > /dev/null

for item in ${DEPS[@]}; do
  vcpkg install $item
done

INCLUDE=$(cat $MANIFEST | jq -r '."$include"')
if [[ -f "$INCLUDE" ]]; then
  echo "Found include $INCLUDE"
  $0 "$INCLUDE"
fi                  

My vcpkg.json this works on:

{
  "name": "sfio",
  "version-string": "1.0.0",
  "$include": "libeen-cpp/vcpkg.json",
  "dependencies": [
    "liburing4cpp",
    "docopt",
    "cli11",
    "boost-lockfree",
    "boost-interprocess",
    "boost-icl",
    "boost-iostreams",
    "boost-crc",
    "boost-accumulators",
    "prometheus-cpp",
    "mio",
    "libmeazure"
  ]
}

Doesn't support vcpkg features or what not, but could be modified to...

Think the problem it that vcpkg need to know about all dependencies up front to figure out the set of features to use.'
Lets say project A uses Foo with feature 1 and project, B uses foo with feature 2, then vcpkg has to install Foo with both features. Potentially, it could install Foo with feature 1, first, and then reinstall it again with feature 1 and 2 when it gets to project B. But that would be a bit wasteful. Also there are suff like overlay ports and triplets in manifests that all projects should agree on. Also there might be version constraints (But Im not familiar with how vcpgk does that). All together it means that doing it incrementally is hard.

As long as all subproject are unconditionally added it is quite easy to create a script that scans all the sub manifest and merges them in to a "master" manifest. But if one should be able to enable/disable different projects that gets more complicated.