# \[Returned for revision\] SE-0303: Package Manager Extensible Build Tools **URL:** \ **Category:** Announcements\ **Created:** [March 18, 2021, 12:24am UTC](https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640 "2021-03-18T00:24:08Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![tomerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tomerd/32/3402_2.png) [@tomerd](https://forums.swift.org/u/tomerd)\ **Post date:** [March 18, 2021, 12:24am UTC](https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640/1 "2021-03-18T00:24:08Z")
The review of [SE-0303: Package Manager Extensible Build Tools](https://forums.swift.org/t/se-0303-package-manager-extensible-build-tools/) has concluded and the core team has **returned it for revision**. The feedback to idea of extending SwiftPM with plugins, the concrete design of the plugin system, and the tradeoffs the design make was very positive. Both authors and users of potential future plugins have provided input that the proposed design would work in real-world use cases, and that today require solutions outside of SwiftPM. However, there were a number of ideas that came up during the review that the core team feels would be good to adopt. 1. The proposed package manifest syntax does not offer a structured way to configure the plugins added to the package. The underlying technical challenge is that in order to support type-safe configuration, the package manager will need to compile & load the plugins prior to be being able to parse the manifest (since its Swift code), causing a chicken-and-egg issue. 2. Technically related to the above, several reviewers pointed out that this having a single dependencies stanza implies the plugins and the package share the same version of the dependencies which could lead to undesirable revlock side-effects. Here too, the more complete solution is to restructure the package manifest to multiple top level "stanzas" (or even multiple files), as described above. 3. The proposal describes that plugins gain access to the file system using simplistic file system abstraction, namely array of `FilePath` (from SwiftSystem). Bazel's depset was mentioned as an alternative for building up input file lists and the arguments for constructing shell commands, which seems like an interesting alternative. Several reviewers pointed our that the plugins API should provide something more useful, for example the type/category of the files, and some filtering/globbing capabilities to make the plugin authors job easier. 4. The proposed API does not provide contextual information about the target platform, which limits the API usefulness for building platform-specific plugins. 5. The proposal describes 3 initial plugin types: `prebuild`, `postbuild`, and `buildTool`, defined as the following: ---
**Author:** ![AlexisQapa](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alexisqapa/32/7159_2.png) [@AlexisQapa](https://forums.swift.org/u/AlexisQapa)\ **Post date:** [March 18, 2021, 9:25am UTC](https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640/2 "2021-03-18T09:25:04Z")
Postbuild could be used for packaging or dsym upload ---
**Author:** ![3a4oT](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/3a4ot/32/721_2.png) [@3a4oT](https://forums.swift.org/u/3a4oT)\ **Post date:** [March 18, 2021, 9:36am UTC](https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640/3 "2021-03-18T09:36:20Z")
> [@tomerd](#): > > Consider removing postbuild given that its utility is unclear. IT can be used for artifact uploads OR notifications. Please do not remove it. ---
**Author:** ![ahti](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ahti/32/604_2.png) [@ahti](https://forums.swift.org/u/ahti)\ **Post date:** [March 20, 2021, 11:11am UTC](https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640/4 "2021-03-20T11:11:25Z")
Wrt. points 1 and 2: One solution I imagine could work quite nicely here, and would be nice even without this particular motivation, would be to compose with the [upcoming script support](https://forums.swift.org/t/pitch-swiftpm-support-for-swift-scripts-revision/46717) and allow manifests to declare build-dependencies together with the import stanzas. This would, I think, lead to a model that is quite understandable to the user, and apart from allowing type-safe configuration for build plugins it could allow common patterns seen in package files to be pulled into libraries. This is, of course, a feature a little bigger than something focused on just build plugin config, but it's such a natural composition of features I think I quite like the idea. ---
**Author:** ![davidjennes](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davidjennes/32/14795_2.png) [@davidjennes](https://forums.swift.org/u/davidjennes)\ **Post date:** [March 26, 2021, 12:54am UTC](https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640/5 "2021-03-26T00:54:04Z")
From a quick check of a bunch of projects I have, `postBuild` can be used to: - Strip extraneous architectures of embedded frameworks (yeah that's still needed in some cases) - Update version number in a few plist files (app Info.plist but also app extensions and symbol files) - Upload symbols files to crash reporting system ---
**Author:** ![shali3](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/shali3/32/16011_2.png) [@shali3](https://forums.swift.org/u/shali3)\ **Post date:** [March 29, 2021, 6:47am UTC](https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640/6 "2021-03-29T06:47:09Z")
IMO these are build script tasks and not a build phase. The tasks you're describing will fit perfectly fine in a travis CI configuration. I think the problem they are trying to solve here is for tools that are required for compilation. Think of tools similar to `clang`. ---
**Author:** ![STREGAsGate](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stregasgate/32/14545_2.png) [@STREGAsGate](https://forums.swift.org/u/STREGAsGate)\ **Post date:** [March 29, 2021, 10:17am UTC](https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640/7 "2021-03-29T10:17:33Z")
In my projects I need to precompile resources. The proposal states access to the package source would be read only. This means the plugins won’t work with the spm resources feature and will instead require manipulating the bundles in the build directory. Bundles aren’t the same across platforms and could change over time, so that would make the tools overly complex. I currently use a command line tool to compile resources into the package source and then let spm do its thing. It would be nice if this feature allowed me to do it all in package. An example would be turning Metal shaders into a Metal Library. I need to do this with directX as well as convert 3D geometry, images, and audio to various formats. The spm resources feature has an option for processing resources. Perhaps that could be rolled into this? A resourceTransform plugin or something like that. Just some thoughts. I’ll try to bring this up for the next revision. ---
**Author:** ![shali3](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/shali3/32/16011_2.png) [@shali3](https://forums.swift.org/u/shali3)\ **Post date:** [March 31, 2021, 8:56am UTC](https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640/8 "2021-03-31T08:56:03Z")
Do you think it's feasible to make it into Xcode 13 with this feature? ---
**Author:** ![quentinfasquel](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/quentinfasquel/32/2642_2.png) [@quentinfasquel](https://forums.swift.org/u/quentinfasquel)\ **Post date:** [April 24, 2022, 2:40pm UTC](https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640/9 "2022-04-24T14:40:52Z")
Any .metal shader in your swift package automatically goes into default.metallib (considered as a processed resources when built with xcodebuild / Xcode) I do believe however that it would be able to customise this since at the moment to have .ci.metal shader files that link against core-image and regular metal shader files, you need a custom Build Rule in Xcode, this is a very specific case that's currently limiting ---
**Author:** ![RbBtSn0w](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/rbbtsn0w/32/17996_2.png) [@RbBtSn0w](https://forums.swift.org/u/RbBtSn0w)\ **Post date:** [April 23, 2026, 3:41pm UTC](https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640/10 "2026-04-23T15:41:47Z")
Have same issues, make the shadow to c++ code.