Run custom shell script R.swift generate resources takes 60 secs regardless of the size of the Resources folder

[paulosilva8]

I have migrated my project to R.Swift 7.2.4 using SPM and the new plugins. However, there is a strange behavior going on right now with the project. In a generic SPM module, the "run custom shell script R.swift generate resources" step is very fast. In an app-extension type takes 60 secs, which is roughly the same time it will take for the main app. The app extensions contains very few resources between them. Also, an issue I see is that these running R.swift script steps are not parallelized by XCode for the app and the app extensions, so the build gets stuck until this step is finished. Is anyone facing such issues?

[paulosilva8]

From further analysis into this issue, I can see that the plugin shell scripts take different command-line arguments and hence the difference in time of execution between an SPM module and an app or app extension. The SPM module plugin will search for resources in the Resources folder of the SPM package and that's it. The app extension plugin will search for the entire project folder looking for resources, recursively. This explains why the app plugin script will take the same amount of time as the app extensions plugin, because on Xcode I can have resources everywhere and simply attribute them to different target memberships in the File inspector pane. There isn't one single place where I am bound to have resources in an Xcode project.
Is there a way to use a plugin for multiple targets? Since we have the app plugin looking for resources everywhere, we could use the app target to prepare the R.generated file for all targets of the Xcode project we would signal it

[tomlokhorst]

R.swift is meant to be used for a single target.

If your project has multiple targets, each target can use its own R.swift configuration.

[paulosilva8]

Yes, that is not the issue here. The issue has to do with the "running custom shell script" build step for R.Swift, which, by the way, runs on very clean or incremental build.
If the R.Swift plugin is used on an SPM target, this shell script contains the arguments --input-type input-files --bundle-source module and it is pointing to a small size folder with the target assets.
In case the Xcode project app or an app extension for that matter, the same script contains the arguments --input-type xcodeproj --bundle-source finder. Well, in a big project this looks for resources in a potential huge folder space with many subfolders. Is there a way we could customize this script to point to a single Resource folder, for instance?

This is the code in the plugin where this is determined: RSwiftInternalResources plugin and as an XcodeProjectPlugin

[tomlokhorst]

I see what you mean.

The fact that R.swift runs on your Xcode project is part of the design goal of the tool. You don't need to configure anything separately: "it just works".

Note that even when scanning the Xcode project, it will take targets into account. So if you have a many files in a folder, but those are not part of your target, they will not be processed by R.swift.
In short, a similarly configured SPM package target should process about as much data as a similarly configured Xcode target.

If you still want to exclude certain things, you can add a .rswiftignore file, or only enable specific generators, see: https://github.com/mac-cain13/R.swift/blob/master/Documentation/Ignoring.md

[paulosilva8]

The fact that R.swift runs on your Xcode project is part of the design goal of the tool. You don't need to configure anything separately: "it just works".

Yes, but on a large project, this type of lookup takes a significant amount of time on every clean and incremental build, which is a problem. 60 seconds on every incremental build is an enourmous amount of time, as I am sure you can understand.

Note that even when scanning the Xcode project, it will take targets into account. So if you have a many files in a folder, but those are not part of your target, they will not be processed by R.swift. In short, a similarly configured SPM package target should process about as much data as a similarly configured Xcode target.

Yes I can understand this statement. But in the majority of cases, when an app is not yet modularized, or it's only partly modularized, the main app lookup for resources becomes a bottleneck. So I am guessing there is no way to add some argument to reduce this lookup scope?

If you still want to exclude certain things, you can add a .rswiftignore file, or only enable specific generators, see: https://github.com/mac-cain13/R.swift/blob/master/Documentation/Ignoring.md

Already using it, thanks!

[tomlokhorst]

I understand your situation. Unfortunately we there's currently no other options than the ones I've listed to speed up the execution time of R.swift.

One more thing you could try:
In this issue #479, people mentioned that the actual running of the .rswiftignore was a significant part of the runtime.
So it might be interesting to see if your .rswiftignore can be rewritten in some way to be faster. Maybe put more into --generators and less in .rswiftignore. I have no experience with this.

[paulosilva8]

I understand your situation. Unfortunately we there's currently no other options than the ones I've listed to speed up the execution time of R.swift.

One more thing you could try: In this issue #479, people mentioned that the actual running of the .rswiftignore was a significant part of the runtime. So it might be interesting to see if your .rswiftignore can be rewritten in some way to be faster. Maybe put more into --generators and less in .rswiftignore. I have no experience with this.

Thank you for this suggestion. The time is spent on the custom shell script so I will close this issue