# Package Manager Extensible Build Tools **URL:** \ **Category:** Package Manager\ **Created:** [March 12, 2018, 8:23pm UTC](https://forums.swift.org/t/package-manager-extensible-build-tools/10900 "2018-03-12T20:23:53Z")\ **Posts on this page:** 1\ **Showing post:** 10
**Author:** ![bppr](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/bppr/32/2415_2.png) [@bppr](https://forums.swift.org/u/bppr)\ **Post date:** [March 13, 2018, 6:29pm UTC](https://forums.swift.org/t/package-manager-extensible-build-tools/10900/10 "2018-03-13T18:29:30Z")
> [@kevints](#): > > The protoc tool is typically installed on the system somewhere in PATH or downloaded into a project build dir and run from there [1]. If the tool is on the system PATH we need a way to express this (and escape the sandbox for it). If the tool is to be downloaded into the build dir we need a way to express that so that the package extension can find the tool. I feel like this is the main point of objection I have with this proposal. It doesn't have a mechanism to configure tools beyond passing them CLI arguments. It doesn't have a mechanism that allows authors to provide a library or API to end-users who might use these tools. This pushes the complexity outward to developers using these libraries, just like `rpath` and the like. While we've been reassured that importing custom APIs into SwiftPM would be "easy", I'm not so sure... and therefore I think pushing this type of workflow out of the package and into the workspace proposal is a far better approach. --- _[View the full topic](https://forums.swift.org/t/package-manager-extensible-build-tools/10900)._