Make it easier to integrate C libraries into Packages

[dschaefer2]

Description

In order to match Swift's powerful C language interop, SwiftPM needs to make it easier to leverage C libraries from the ecosystem. A common practice now is to vendor these libraries into new Swift specific repos. This creates a maintenance burden where significant work is needed to keep up with releases of the upstream repo. It should be possible to express a dependency on that repo in its raw form, then added the necessary machinery to create Swift modules for the library without having to copy the source over.

I just ran into a good example: raylib which is a great library to introduce programmers to game programming. There is a swift binding for it which vendors raylib's source. We should be able to create a swift binding for that library without copying source. There are modified sources in the binding library, how do we accomplish all this?

My initial thought was to be able to add it as a dependency and leverage SwiftPM's dependency resolution to download the right version of the C library. The Swift Package would then specify a recipe needed to morph that source including adding things like the necessary module map or bridging header to allow Swift modules to reference the API of the library. Build plugins would then be injected to build the library using its native build system to create the artifacts that can be linked into the Swift application.

[jakepetroules]

The recently-introduced https://github.com/swiftlang/swift-toolchain-sqlite is a good example of this, too. Although in this case we did want to copy the sources to avoid having a network dependency on sqlite.org.

I think there's two distinct parts to this:

• Allowing re-use of C libraries without defining a formal repository + package for the C part (e.g. let me depend directly on some sources, potentially from a network URL like https://sqlite.org/2024/sqlite-amalgamation-3470200.zip)
• Providing the ability to mirror assets like the above URL to ensure security and control, especially for corporate networks

[dschaefer2]

Agreed. I think making mirroring easier is something we want to accomplish for package dependencies as well. It needs to be a first class citizen.