Moving your question from the swift-build thread here @dschaefer2
If there are practical, impactful changes that can be implemented within a reasonable timeframe, we can discuss them. However, this pitch is intentionally focused on a specific use case—deployment with shared libraries and evolution enabled on Linux in controlled environments. As @stemmetje noted, this has been a persistent pain point for at least six years, often derailed by debates over a "perfect solution."
Talking about pros and cons, I can only give my take on it trying to summarize;
Pros
- Enables Swift server-side Linux deployments with shared libraries and evolution support for controlled environments (both enterprise/service based ones, as well as ISV-style ones with shipment of SDK:s)
- Provides practical experience and a possible stepping stone for future possibly more generic solution
- Removes a significant friction point for also internal workflows (e.g. CI)
- Sponsored implementation from the community, minimising core SwiftPM engineering time
- May increase incentive to follow up with a more generic solution if these deployments get traction
- Should not conflict with potential future more generic solutions
- Removes need to ship custom toolchains to customers with XCFramework support enabled on Linux (what we at Ordo One need to do today for full disclosure... really would rather not.)
Cons
- Support of the feature over time (including possible need to do extra work in the context of swift-build)
- Can be mystifying to non-expert users (although that would be true for most expert-level features...)
- May reduce incentive to instead do a more generic solution (in the eye of the beholder...)