This sounds fantastic if I understand the implications correctly ā is SWBBuildService the "new name" for XCBBuildService? I don't see any references to SWBBuildService in Xcode 16.2 but it looks like the symbols in XCBBuildService are more or less the same (specifically, Xcode.app/Contents/SharedFrameworks/XCBuild.framework/PlugIns/XCBBuildService.bundle/Contents/Frameworks/XCBBuildService.framework/XCBBuildService)
1 Like
With Swift SDKs and/or toolsets it's already possible in main development snapshots when debugger (for swift-run) and testRunner (for swift-test) properties are specified. The implementation is independent of the build system used, we just apply the launcher from these properties in CLI arguments after build products are ready. See these PRs for details:
3 Likes
Yes, those are the same framework.
1 Like
That's awesome, I wasn't aware we had that!
1 Like
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.
For us the use case is a little different but still important. We've developed a fairly extensive collection of internal libraries each of which, naturally, contributes to the overall build time of, for example, our web server software that runs on Linux. With things as they are currently, every time our CI infrastructure builds the final project (in order to, for example, run automated tests on a pull request), it has to re-compile the entire dependency chain from scratch. This ends up taking quite a bit of time as well as incurring a not-insignificant cost to run the CI system.
We could, in theory, build some or all of these libraries separately, then manually embed the compiled artifacts in the Docker container that the CI uses as "system" libraries. But then we would lose all of the dependency management and resolution features of the Swift package manager.
I know that Linux is not a monolith and something of a "Wild West" collection of operating systems, and I fully recognize that a fully generalized, covers-all-cases solution for binary Linux dependency management is a daunting task. But this seems like a classic example of letting perfect being the enemy of good: there's been so much worry for so long about covering all cases that there's been no progress on covering the simplest and almost certainly most common case: taking a compiled artifact with a known, pinned distribution, version, and architecture of Linux (e.g Ubuntu 24.04 on amd64) and a known, pinned version of Swift (e.g. 6.0.3) and re-using that artifact in another instance of that exact same environment.
6 Likes
Without any intention to invalidate your pain point report, but have you tried "just" using SwiftPM's cache in your CI setup?
I have found it to work quite well - in both "direct" CI cases, as well as for docker builds.
For build times specifically, you get a lot of bang for little buck without opening the can of worms that is binary distribution and/or dynamic linking.
If I am understanding you correctly, I think your suggestion is to re-use the cache from one build of the final project to the next?
The main problem with that is that SwiftPM's cache management isn't completely reliable (see also this thread on server-side pain points); I think we've all experienced having to occasionally delete the build folder in order to resolve a build problem. We're reluctant to introduce that element of unpredictability to our CI pipelines.
Since you mentioned using this technique, have you run into this sort of problem? If so, how did you address it?
I'm going the spend the next few months learning about this new treasure that has dropped for SwiftPM to understand what's possible. I've had many requests to extend the capabilities of SwiftPM and I believe Swift Build will help us get some of those in place sooner than later.
However for now, we're very busy getting SwiftPM on top of Swift Build with its current functionality. Hopefully by the summer I can start putting ideas together and start opening Evolution proposals for the community to give their feedback on.
In the meantime, keep the ideas coming. Exciting times ahead.
7 Likes
Sounds great, Doug! Of course the community is welcome to ideate and propose enhancements as well - definitely a "we" situation. 
That said, to clarify what I think you were trying to emphasize to our community partners, our current focus on getting SwiftPM re-platformed on top of Swift Build means it may be best to largely hold off on proposals related to new manifest API until that transition is complete, so that we don't spend effort trying to implement that functionality in two different build system engines at once.
iām curious to know how this will impact [Pitch] Replaceable Library Plugins , which does not introduce any new API to the manifest, but does add some minor extensions to the ArtifactsArchiveMetadata JSON format, and changes nine files within the SwiftPM source code.
RLPs are very mission-critical to a number of key stakeholders in the community, especially the server-side Swift community, and some members of the community have invested significant resources into advancing this feature. i think it could become more challenging to justify additional external investment in Swift in the future if existing investments, like [Pitch] Replaceable Library Plugins , were swept aside or allowed to become stale because of conflicting timelines between organizations. i think it is important for both Apple and community contributors to coordinate the upstreaming of these features to avoid wasted effort.
2 Likes
Of course, but I'd like to start socializing the ideas so when the transition is complete we can hit the ground running. I don't want to hold up the ecosystem longer than we have to.
Which to your question @taylorswift, we need to see what that Pitch means in the Swift Build context. It may mean implementing it twice. But I'd like to see more analysis on the Pitch about the pros and cons. We have a lot of features that have been bolted on to SwiftPM that may have been better done if we took a step back and made a bigger change that gave us a bigger benefit. Once a feature is in, we can't really take it back as people start to use it.
3 Likes
As mentioned in the post, I found the plain SwiftPM cache to mostly work just fine in CI. I only remember having to manually clear it once, but that was a while ago.
My suggestion: Just give it a try. It is typically just a few lines of config, and if it doesn't work reliable, just remove it again.
Technically speaking, anything in Sources/Build pertains only to --build-system native.
1 Like