vcpkg has multiple types of registries -- the "built-in" registry which is just the vcpkg repo (https://github.com/microsoft/vcpkg) that most people use. Then there are "git" custom registries which let you serve your own packages for internal use. Clients may want to use vcpkg to pull in our library and we want to consume this library via vcpkg via our private repositories. Making this repo it's own registry is a solution for that. We could also explore PRing it to the main built-in registry but this allows for better iteration speed.
Also, most people make their registry a separate repository but I didn't see a need for that yet since we just have one package to serve out. We can split it out to another repo if needed later.
whats the end goal? this repo is not buildable as a pure vcpkg package, because it requires CMake level inputs to actually be useful (see vars in CMakePresets.json) + overlays + triplets.
vcpkg has multiple types of registries -- the "built-in" registry which is just the vcpkg repo (https://github.com/microsoft/vcpkg) that most people use. Then there are "git" custom registries which let you serve your own packages for internal use. Clients may want to use vcpkg to pull in our library and we want to consume this library via vcpkg via our private repositories. Making this repo it's own registry is a solution for that. We could also explore PRing it to the main built-in registry but this allows for better iteration speed.
Also, most people make their registry a separate repository but I didn't see a need for that yet since we just have one package to serve out. We can split it out to another repo if needed later.