[SR-15357] [SwiftPM] support for vcpkg

[stevapple]

Previous ID	SR-15357
Radar	None
Original Reporter	@stevapple
Type	New Feature

Additional Detail from JIRA

Votes	1
Component/s	Package Manager
Labels	New Feature, windows
Assignee	None
Priority	Medium

md5: eead7599c3901e26b766af3bf90310ff

Issue Description:

vcpkg is a C++ library management tool developed by Microsoft, which is cross-platform and gains first-class support on Windows.

SwiftPM support for vcpkg will largely ease the effort of linking an external library on Windows.

[stevapple]

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

[neonichu]

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.

[stevapple]

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 swiftlang/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.

[neonichu]

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.

[stevapple]

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.

[neonichu]

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.

[Keithcat1]

This would make building SDL2 on Windows easier, for instance. Some way for SwiftPM to invoke CMake during the build process would be nice.

[dschaefer2]

Interesting. I haven't used vcpkg. I'll take a look.

I'm also looking at ways we can call CMake and ninja and extract the libraries so we can wrap them in a module map. Lots of examples where this would be useful.

[xtyxtyx]

How about introducing a more generic mechanism for building third-party code, similar to Rust’s build script? This would provide more flexibility, allowing vcpkg support to be implemented as a Swift package (like vcpkg-rs) in userspace, rather than having to build everything into SwiftPM.