Currently I’m using a build tool plugin declared as a source target, not a binary target.
It’s used for code generation, and so pulls in SwiftSyntax which is a pretty hefty dependency.
When I use it in Xcode, if I build a target which uses the said build tool plugin, the build tool plugin gets built with the same configuration as the target.
For debug and release builds, the extra delay is manageable, but when building a profiling build it can take a really long time, because it rebuilds all of the build tool plugins with the profiling configuration, even though the profiling information isn’t used at all.
Is there a way to work around this? I think in an ideal world, build tool plugins would always be built with the release configuration regardless of the target configuration, since they can’t easily be debugged anyway. And that way they wouldn’t need to be rebuilt whenever the target configuration changes: You would only need to build it once.
I doubt there is a way to work around it at the moment. For expediency, the initial implementation of plugins simply included them in the same graph as everything else. If both a plugin and a real target link against the same dependency, there is currently only one instance of that dependency. That means SwiftPM does not keep track of why a dependency is needed, and cannot communicate it to Xcode. Hence neither tool is able to treat the dependency differently between the two situations.
But that is not how anyone expects it to work in the long run. Once the plugin implementation is split out into separate graphs, they could safely use conflicting versions of shared dependencies, could be built only in release mode, could be kept in a global cache, etc. Commenting on or creating a new issue is a way of communicating to the developers which features are the most pressing to users. You can also submit pull requests if you can figure out how to implement something yourself.