I'd like to pick this up and implement .vcpkg as a system library provider in SwiftPM. Vcpkg products can be easily consumed by SwiftPM because it provides out-of-the-box support for pkg-config, and the only thing we need is to add it to search path.

As the first step of it, I’d like to start from supporting installed libraries first, which has a mostly identical layout to /usr. To confirm the install root, I would like to make use of some environmental variables, including VCPKG_ROOT, VCPKG_TARGET_TRIPLET, VCPKG_HOST_TRIPLET and VCPKG_INSTALLED_DIR. These were used as customizable settings for CMake integration.

WDYT? @abertelrud @neonichu @tomerd @elsh

Personally, I think system library providers in their current form are a stopgap and inherently not scalable. We should find a way to provide them through plugins before adding any new built-in ones that aren't absolutely necessary. It's not feasible for SwiftPM to have knowledge of every other package manager in existence.

Then we should, at least, enable plugins to provide header & library as a target directly, but it doesn’t seem possible for now.

I propose to add Vcpkg because we can make use of the .pc files it produce, just like what we do with HomeBrew. Enabling Vcpkg support, together with apple/swift#60679, could make it possible to easily bootstrap SwiftPM and eliminate the need of building new developer tools with CMake on Windows (also unblocks testing on CI). This also matches the goal of Swift’s path on having more Swift in Swift.

I'm not talking about the existing plugin types, but rather a new one that would allow creating system library providers outside of SwiftPM's main codebase.

I don’t think a the provider entry matters very much (personally I think it should be gone and replaced by document). By supporting Vcpkg, I intended to let SwiftPM automatically find its pkgconfig directory.

Extracting such functionality into a plugin sounds interesting, but I would doubt the benefit of moving it out of SwiftPM code base. It’s up to the user which PM to be used, but the target is declared by the library author. And supposing that the user is writing a downstream library, he/she cannot add the plugin to the package manifest either. Also, hardcoded provider in manifest but not SwiftPM makes it harder to be ported to a new platform.

What we need may be modularizing and decoupling the SwiftPM implementation IMO. This is not against adding new features in.

Sorry, I wasn't super clear here, it is correct that system library providers don't do much today. What I am thinking of is a similar mechanism that can be provided through plugins which actually do handle package manager specific tasks (e.g. finding the homebrew/vcpkg/... installation) and it sounds like you're saying the same thing. This will probably require some type of way to install plugins that SwiftPM can use independently of individual packages.

Neither the package author, nor the SwiftPM team, should be deciding what the mechanism is to install system libraries on user's systems that are required by particular packages.