Vend modular products as well as monolithic product

[furbytm]

Currently in order to link with any of the OpenUSD xcframeworks, we only have the option of linking against the single monolithic OpenUSD product.

Would it be possible to add the various individual OpenUSD libraries into products: [] so they can be linked against individually?

Consuming packages would then be able to do something like the following:

.target(
  name: "MyLibrary",
  dependencies: [
    .product(name: "Usd_Arch", package: "SwiftUsd"),
    .product(name: "Usd_Tf", package: "SwiftUsd"),
  ]
)

I would be happy to contribute this change, if you feel this would be a value add to the project.

[maddyadams]

Hm, right now the "overlay targets" (swift-package/Sources/OpenUSD and swift-package/Sources/_OpenUSD_SwiftBindingHelpers) assume that they can generally use types from all of OpenUSD's libraries, so I think this change would end up being pretty involved. (There is some guarding like #if canImport(SwiftUsd_PXR_ENABLE_IMAGING_SUPPORT) to support no-imaging builds of OpenUSD, but I'm not sure how well that would scale to selectively using individual OpenUSD libraries.)

Do you have a use case in mind where it would be useful to selectively link against only some OpenUSD libraries?

[furbytm]

Do you have a use case in mind where it would be useful to selectively link against only some OpenUSD libraries?

Thanks for the context on the overlay targets, that makes sense, and I agree that granular per-library products would be a significant lift given how the overlays are currently structured.

• The current use case: I maintain wabiverse/swift-usd, which uses apple/swiftusd by default on Apple platforms and builds OpenUSD from source for Android, Linux, and Windows. Because of the cross-platform requirement, I've had to implement some things independently that end up diverging from the apple/swiftusd approach in user-visible ways.

• One relevant example: I've added a Tf_SharedPtrRetainReleaseHelper that bridges std::shared_ptr non-intrusive reference counting to Swift ARC for types that aren't TfRefBase subclasses, and added SWIFT_SHARED_REFERENCE annotations to types like UsdImagingGL, HgiMetal, Hgi, and HgiGL. This makes them reference types in Swift (usable with let), whereas in apple/swiftusd they're value types (requiring var) - a real API surface difference for consumers writing code portable across both.

Granular product linking would help here because it would let me depend on apple/swiftusd selectively: using the individual .xcframework binaries for their compiled symbols and linkage, while supplying my own modified headers for the Swift-facing API surface where the ARC semantics differ. Right now the monolithic product is all-or-nothing, which forces a harder choice.

Important

These granular products would be intended to be consumed by C++ targets rather than pure Swift targets, so the overlay complexity you described wouldn't apply to this particular use case. That said, if the intended design for this package is that all declared products target interoperabilityMode(.Cxx) Swift consumers only, then this request would conflict with that direction architecturally - worth flagging in case that's a constraint.