Synthesize SWIFTPM_MODULE_BUNDLE for targets with Objc sources #4902
Conversation
| // FIXME: Is there any better way than GCC_PREFIX_HEADER? And what if the target would have set this already, then we're breakings something here. | ||
| var settings = modifiedTarget.settings?.base ?? SettingsDictionary() | ||
| settings["GCC_PREFIX_HEADER"] = .string(headerFile.path.url.relativePath) | ||
| modifiedTarget.settings = modifiedTarget.settings?.with(base: settings) |
There was a problem hiding this comment.
This needs to be discussed, there's hopefully a better way, shouldn't stay like this.
The SPM implementation does this: -include path/to/resource_bundle_accessor.h
See also:
There was a problem hiding this comment.
Could this be added to the target headers directly rather than via build settings?
danieleformichelli
added
the
changelog:added
There was a problem hiding this comment.
Thanks for contributing this @plu
If I understood and followed along the issue, this issue mostly relate to when using the Dependencies feature of Tuist to integrate Swift Packages.
The changes made here will apply to all projects (ones that leverage the dependencies feature and ones that don't!) which is most likely not the intention here. Additionally even when using the dependencies feature I suspect this only needs to be applied to the external projects (the Tuist managed swift package projects).
Some suggestions:
- Create a separate mapper which contains this logic and only applies for projects / targets managed by the Dependencies feature
- Potentially omit the current mapper which generates Swift bundle accessors for projects / targets managed by the Dependencies feature as those won't be using those files
@danyf90 is something like this possible? Is there a way to distinguish between projects to control which mappers run?
| // FIXME: Is there any better way than GCC_PREFIX_HEADER? And what if the target would have set this already, then we're breakings something here. | ||
| var settings = modifiedTarget.settings?.base ?? SettingsDictionary() | ||
| settings["GCC_PREFIX_HEADER"] = .string(headerFile.path.url.relativePath) | ||
| modifiedTarget.settings = modifiedTarget.settings?.with(base: settings) |
There was a problem hiding this comment.
Could this be added to the target headers directly rather than via build settings?
I think it's possible (there should be an |
Nice! found it https://github.com/tuist/tuist/blob/main/Sources/TuistGraph/Models/Project.swift#L60
Valid question :) As things stand, ObjC can still leverage the generated bundle as I believe it has an For the above, the generated files would need to have a stand alone implementation to finding the bundle as opposed to referencing the Swift implementation and wouldn't need to have |
|
This PR has been marked as stale because it's been opened for more than 30 days. If no action is taken, it'll be closed in 5 days. |
@kwridan From the linked issue, it looks like there is some OBJC code in a dependency that tries to access it, so I guess SPM generates it and we need to do the same (maybe only for SPM generated targets?), isn't it? |
|
Closing for inactivity, if you want to continue feel free to reopen it |
|
Sorry for not responding, I have completely missed the notification for the comments on this PR :(. Unfortunately our internal priorities have shifted, and currently it does not look like we're going for Tuist anymore. |
Resolves #3785
Short description 📝
Synthesizes two more files into
Derived/Sources, next to the already existingTuistBundle+TargetName.swift:TuistBundle+TargetName.hTuistBundle+TargetName.mOnly if the target contains Objective-C header files. The implementation is trying to mimic what SPM does.
How to test the changes locally 🧐
You can try to use the attached example app from #3785.
Checklist ✅
changelog:added,changelog:fixed, orchangelog:changed