+1.
I have more static library depencencies in my project and I want use SwiftPM to manage it.
I am wondering whether using frameworks/libraries as binary artifacts makes it feel like binaries should be regarded as products rather than targets in the manifest. There are a few considerations to take into account for the question of binary products vs. targets:
- Targets allow configuring linker/compiler flags; this ability might be necessary for static libraries
- There are already
systemLibraryTargetswhich are essentially dependencies on pre-existing binaries on the host system - Targets represent a single module, the same is true for one XCFramework
- Currently there is no way to depend on products, so mixed binary and source packages might be harder if we go with a binary product approach
- Analogy with what currently is being produced by source packages (dylibs => product)
Am I missing any further considerations? Technically, it seems like targets are still the better fit.
This has actually been somewhat annoying, since you cannot make two executables link against the same dynamic library in a single package. Instead you have to live with the library being tripled, since its targets get statically linked separately into each executable, and then the isolated library product is still built.
There is also no way to have a dynamic library that is only an implementation detail; you have to vend it.
I would say targets are categorically better.
In general it would be nice if a “product” meant nothing on its own except the exposure of an attachment point for clients.
All the additional functionality currently attached to products could have been even more useful at the target level. That includes the ability to select static vs dynamic, and the aggregation of sub‐targets. To me, the tangling of those sorts of things with client access control seems detrimental.
2 Likes
This proposal is under review now, see the review thread .