Any way to override build setting of Package's Resource target?

Troubleshooting & how to
,
1

Question or problem

I want to override build Settings for Package’s Resource target, but it seems like Tuist does not support this case.
Tuist does support overriding build settings of Package targets ( deployment target, linker options, bundle id etc… which is super cool)

I have a Package contains various Metal code.
Which contains variety of options and macro which switches between metal compiler settings and linker options.

Metal library is packages as an Resources bundle in Tuist so I would expect something like below should work

#if TUIST
    import struct ProjectDescription.PackageSettings
    import typealias ProjectDescription.Destinations

    let packageSettings = PackageSettings(
        // Customize the product types for specific package product
        // Default is .staticFramework
        // productTypes: ["Alamofire": .framework,]
        productTypes: [
            :
        ],
        targetSettings: [
            // this is the Resource bundle generated by tuist
            // default depolyment is iOS 13.0 macOS 10.15, and I can not change it
            "spine-ios_SpineSwift": .settings(
                base: [
                    "IPHONEOS_DEPLOYMENT_TARGET":"16.0",
                    "MACOSX_DEPLOYMENT_TARGET": "12.0",
                    "MTL_LANGUAGE_REVISION":"2.3",
                ],
                debug: [
                    "MTL_ENABLE_DEBUG_INFO": "INCLUDE_SOURCE"
                ]
            )
        ]
    )
#endif

Expectation

I would expect, or a way to override implicit Resource target generated by tuist which will be the Bundle.module like other package targets.

Context

  • Tuist version: 4.46.1
2

Hey :wave:

There is currently no way to change the build settings of the generated resource bundle target. As a workaround, you can change the SpineSwift product type to be .framework if that’s an option – in which case, we wouldn’t generate the resource bundle target.

There are two possible options we have to enable that:

  • Propagate the settings from the sources target to the generated bundle target here
  • Bring this PR back that got reverted due to some regressions it introduced. With that PR, we could skip generating the resource bundle target in most cases and instead embed a static framework directly.

The former would definitely be less work, although the latter is probably a better long-term solution.

Would you be up to look into the former (propagating settings)? The ResourcesProjectMapper should be the only place that would need to get updated.