search

MobileNativeFoundation / rules_xcodeproj

Bazel rules for generating Xcode projects.
MIT License
502 stars 76 forks source link

Feature Request: Generate Xcode Previews friendly schemes #1384

Open ra1028 opened 1 year ago

ra1028 commented 1 year ago

Description

We'd like to avoid using _CompileStub_.m as much as possible and display a proper source file list in Compile Sources to enable SwiftUI Previews.

Motivation

Since our product is composed of hundreds of static libraries, we would like to add a dedicated ios_framework for each module instead of building a huge ios_application for SwiftUI Previews. However, as described here, those dynamic frameworks will contain only _CompileStub_.m if their primary module is included in the dependency graph of other top-level targets.

The current rules_xcodeproj's design is reasonable enough, but in a real world project, it's common for a module to be included in the dependency graph of multiple top-level targets like ios_unit_test and ios_application, so you may not able to use SwiftUI Previews naturally like native Xcode.

For now, we have solved this by generating Xcode projects focused on a specific ios_framework, but it would be great if rules_xcodeproj solves it in a comprehensive approach.

brentleyjones commented 1 year ago

If the swift_library is the primary dependency of an ios_framework, and that framework is set via frameworks on other targets (ios_framework, ios_application, and ios_unit_test), you won't get the _CompileStub_.m. So it's not exactly true that the library can't be in the dependency graph of another top-level target, it's just that the framework also has to be in that dependent graph.

I do get the desire for this to be different. And I think I can improve this for BwB down the line. But for now, this isn't any different from Xcode where a certain target is only one type (a static library or a framework) and if you want it both ways you would create two distinct targets.

brentleyjones commented 1 year ago

To be clear, this is 100% a BwX-based constraint, and I will be able to resolve it for BwB at a minimum. Part of moving target merging into Starlark was to resolve this issue. Ideally though I can (partially?) solve this for BwB as well, but it involves complicated search path modification that isn't possible yet.

ra1028 commented 1 year ago

I do believe that defining the dynamic framework and static library as distinct targets would be the proper solution to this problem, but it leads to another problem in that project generation involving multiple targets with the same module_name fail. Using a different module_name wasn't possible since it could be in the source code as a namespace.

Anyway, I don't think at least the current approach is wrong, but I look forward to further useful improvements in the future.

joprice commented 5 months ago

Is there an any example of this setup? I can't seem to get rid of the CompileStub.m generation even with framework consuming a swift_library.

brentleyjones commented 5 months ago

Have you tried the new incremental generation mode? In the legacy generation mode if a library wasn't able to be merged into any of its dependent targets, then it wouldn't merge at all. For example, this could happen if you had a test without a test_host. In incremental generation mode that restriction has been lifted.

joprice commented 5 months ago

I haven't tested with that. I'll try this week and see if I still have the issue.

joprice commented 5 months ago

@brentleyjones After switching to incremental, I was able to get a preview going for one framework. Thank you! I'm going to wrap a few more libraries and report back if I hit any other issues with those.

joprice commented 4 months ago

I have all my previews working except for one which is a widget, where the error says it needs to be embedded in an app to be used in previews. This even happens when selecting the generated target of "XExtension in Y", where X is the widget name and Y the app name that it's embedded in. Is there any extra setup required for widget previews or should they not be expected to work yet?

brentleyjones commented 4 months ago

Does this repro in one of our examples, and if not, can you make a PR that adjusts the example to get it to repro? Then we can look into it. All previews are expected to work. This might be a case where we need to add the extension to a Embed App Extensions phase (which we removed because it wasn't necessary for anything) to get Xcode to see the relationship that exists.