hassila
(Joakim Hassila)
February 2, 2025, 5:33am
16
Also very happy to see this happen, thanks for open sourcing it!
Just would like to reply to this one shortly (and can follow up in the other thread on RLP linked to below as it may be more suitable).
jakepetroules:
I’d encourage reading up on [PITCH] Support for binary dependencies - #74 by jakepetroules if you haven’t already, which contains a lot of great background information and some of the difficulties on Linux in particular due to it having such a vast number of possible ABIs and no clear and canonical way to identify them.
Quoting from that link:
I would like to see a compelling argument for why we absolutely need binary packages on Linux when we have the system package manager to handle the vast majority (if not close to 100%) of those use cases, including for closed-source proprietary packages (of which there are few to begin with).
I just want to clearly state that there is a clear and important use case for those of us who wants to support customers building plugins vs. a resilient API in a controlled enterprise environment (where we as an ISV vend an API that our customers makes use of, but with strict constraints and control on runtime platform and toolchains used/supported). Happy to elaborate as needed, but it is a proven need with a few decades of background experience in various shapes and forms.
Some background here:
main
← ordo-one:optional-linux-xcframework-main
opened 09:48AM - 10 Jan 24 UTC
Provide experimental support for XCFrameworks for Linux for well-defined, identi… cal, deployments.
### Motivation:
Providing informal, experimental support for (very) heterogenous cluster deployments on Linux as discussed previously in https://github.com/apple/swift-package-manager/issues/5714
It allows for deployments which use XCFrameworks and library evolution on identically patches / toolchains on Linux as an interim escape hatch until wider support might be available.
### Modifications:
Enable XCFrameworks for Linux if the `_SWIFTPM_EXPERIMENTAL_LINUX_XCFRAMEWORK` environment variable is set.
### Result:
Users may experiment with library evolution and XCFrameworks on Linux without having to roll their own toolchains while waiting for wider support for shared libraries / evolution on Linux in general.
The default behavior remains unchanged and there should be zero impact for users who doesn't set this environment variable.
opened 10:45AM - 09 Aug 22 UTC
enhancement
### Description
# Background
We have an enterprise-style application where we … have a large number of libraries (swift packages) that we'd like to be able to evolve independently using library evolution and to dynamically link them to a large number of consumers.
Basically adding binary dependency support to a dynamic library generated using SPM similar to XCFrameworks.
I've read https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md and would like to suggest a first step could be to cater to this kind of 'enterprise' deployment scenario rather than taking on the full 'many linuxes support everywhere' - we have full control over deployment operating system and swift toolchain (we can mandate for our customers what they must have to run the software and would do builds for a small number of deployment environments that we support).
The artefact bundle format seems that it would suffice for such a scenario.
So trying to break down what's needed (perhaps missing something):
- Support for binary dependencies also for Linux (preferably using `artifactbundle` format so we can have both macOS and Linux in a single dependency if putting things in the right places)
- Support for enabling library evolution for SPM packages generating dynamic libraries on both macOS and Linux (accepting the requirement for same toolchain on Linux)
I think this single-linux-distribution as a first step could be very useful not only for us, but also for others - and help as a stopgap deployment measure.
See also related discussions / issues:
https://github.com/apple/swift/issues/60458
https://forums.swift.org/t/use-a-dynamic-library-in-a-swift-package-on-linux/59510
https://forums.swift.org/t/availability-when-using-library-evolution-resilience-for-third-party-libraries/59341/3
etc.
Also recently added:
https://github.com/apple/swift/issues/66156
### Expected behavior
_No response_
### Actual behavior
_No response_
### Steps to reproduce
_No response_
### Swift Package Manager version/commit hash
_No response_
### Swift & OS version (output of `swift --version && uname -a`)
_No response_
and a resulting warm and fresh pitch for a limited solution that supports this use case (instead of dismissing Linux as too complex and impossible to solve).
4 Likes