My vcpkg registry. Initially created as an example for this article, but then became an actual registry that I use myself for everyday development.
Although a good portion of the ports here are based on the ports from the Microsoft's registry, it is not my intention to just duplicate stuff from there, and in many cases those ports have certain modifications.
Why would one make one's own ports instead of relying on the Microsoft's registry?
I'd say, in most cases one should probably do exactly that - just use the Microsoft's registry as the main source, at the very least because there is unlikely to be a registry bigger than theirs. And since many projects are using it too, it will be easier to collaborate with them, as you'll be in accordance on dependencies sources and applied patches, file names, paths to public headers and so on.
But having been maintaining projects at my place of work and also personal ones for a while, I eventually discovered that I don't always agree on how patching/building/installation is done in some of the ports in the Microsoft's registry. At the same time, not all of my "disagreements" can be proposed as improvements to their registry, because some of those are specific to my particular needs, so they are likely to be of no use for a broader audience. Hence my own registry, where I can do all sorts of crazy things I might need.
It can be used just like any other vcpkg registry, thanks to Microsoft being very open about the whole thing.
As described in the article, create a dummy project:
./dummy/
├── vcpkg-configuration.json
└── vcpkg.json
vcpkg-configuration.json
(with Microsoft registry as a secondary source):
{
"default-registry":
{
"kind": "git",
"repository": "[email protected]:retifrav/vcpkg-registry.git",
"baseline": "ebee5c267dd774f06967c6459d0c5ae6e74a5033"
},
"registries":
[
{
"kind": "git",
"repository": "[email protected]:microsoft/vcpkg.git",
"baseline": "8b04a7bd93bef991818fc372bb83ce00ec1c1c16",
"packages":
[
"microsoft-signalr"
]
}
]
}
vcpkg.json
:
{
"name": "some",
"version": "0",
"dependencies":
[
{
"name": "curl",
"features":
[
"tool"
]
}
],
"overrides":
[
{
"name": "curl",
"version": "8.1.2"
}
]
}
and then:
$ vcpkg install
A CMake project, as described in the article:
./some-project/
├── src
│ └── ...
├── CMakeLists.txt
├── vcpkg-configuration.json
└── vcpkg.json
vcpkg-configuration.json
(with Microsoft registry as a secondary source):
{
"default-registry":
{
"kind": "git",
"repository": "[email protected]:retifrav/vcpkg-registry.git",
"baseline": "ebee5c267dd774f06967c6459d0c5ae6e74a5033"
},
"registries":
[
{
"kind": "git",
"repository": "[email protected]:microsoft/vcpkg.git",
"baseline": "8b04a7bd93bef991818fc372bb83ce00ec1c1c16",
"packages":
[
"microsoft-signalr"
]
}
]
}
vcpkg.json
:
{
"name": "some",
"version": "0",
"dependencies":
[
{
"name": "curl",
"features":
[
"tool"
]
}
],
"overrides":
[
{
"name": "curl",
"version": "8.1.2"
}
]
}
and then:
$ echo $VCPKG_ROOT
$ cd /path/to/some-project
$ mkdir build && cd $_
$ cmake -G Ninja -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_TOOLCHAIN_FILE="$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake" \
..
$ cmake --build .
You can use custom triplets from triplets
folder both with vcpkg tool:
$ vcpkg install \
--overlay-triplets /path/to/vcpkg-registry/triplets \
--triplet decovar-x64-windows-static-md-clang
and with CMake:
$ cd /path/to/some-project
$ mkdir build && cd $_
$ cmake -G Ninja -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_TOOLCHAIN_FILE="$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake" \
-DVCPKG_OVERLAY_TRIPLETS="/path/to/vcpkg-registry/triplets" \
-DVCPKG_TARGET_TRIPLET="decovar-x64-windows-static-md-clang" \
..
$ cmake --build .
Checks that declared rev-parse hashes in ports versions match their actual values:
$ cd /path/to/vcpkg-registry
$ ./scripts/check-versions-and-hashes.sh
More details here.
Merges vcpkg installation with project installation:
$ cd /path/to/project
$ python /path/to/vcpkg-registry/scripts/install-vcpkg-artifacts.py \
--cmake-preset vcpkg-default-triplet \
--vcpkg-triplet arm64-osx \
--blacklist "vcpkg-cmake,json-nlohmann"
More details here.
master
- ready to use, tested ports;experimental
- drafts, scraps and experiments, ports from this branch are not done and are unlikely to work.