Swift Package Manager already supports building Swift, C, C++ and assembly code.
I've just come up with this crazy idea: what if we allow SPM to build Rust targets?
For now I have the following in mind:
Obviously, for building Rust targets the rust toolchain has to be installed.
We don't use Cargo for building Rust targets, but rather invoke rustc directly. We could allow Swift packages to depend on Cargo packages in the future, but that seems nontrivial.
Rust targets can only depend on other Rust targets. Swift or Clang targets cannot depend on Rust targets. Why? Because it would require a lot of work. Later we could allow Rust targets to have the "include" directory just like Clang targets, which would contain C headers for that target so that the Rust target could be used from Swift using those headers (just like C++ targets today can be used from Swift via C headers).
I've started working on this in my SPM fork, but even basic functionality is yet to be implemented.
However, I wanted to know if this kind of functionality is desired by the community at all, and if yes, would it be accepted by the project maintainers?
I would be very interested in seeing more community involvement in trying to help Rust and Swift work closer together. I can't speak for the Swift Package Manager team, but I think this kind of investment would be very valuable. Even if it didn't land in Swift Package Manager directly, it would be a useful test case for what kind of functionality is required for some kind of "external build tool" infrastructure.
For my part, I think the real value is unlocked by allowing SwiftPM to understand Cargo in some form, even if that's in the form of an external build tool. This shouldn't need SwiftPM to perform a full dependency resolution of the Cargo dependency graph, just to be able to treat Cargo as a black box from which it can get an answer. This seems like a good fit for the "External build tool" idea @ddunbar has been noodling on.
Interestingly, Cargo has a thing called build scripts which can be used to interoperate with other build tools. For example, here the author creates a Cargo package that depends on a CMake project.
I like this approach even more than the ad-hoc support. But it requires a lot of design work.